Writing a Technical Case Study

Technical case study problem sections: quantify the symptoms, diagnose the root cause structurally, and explain why you chose the approach you chose over the alternatives you considered.

Option B models this structure precisely:

① Specific numbers as symptoms — "8.4 seconds p99 vs 2-second SLA", "4.2% fraud detection timeouts", "45-minute manual recovery" — symptoms are what the business experienced. Numbers make them falsifiable and comparable to the reader's situation. "Performance issues" (Option A) is not a symptom; it's a category.

② Root cause framed as a structural insight, not a blame — "the root cause was not load; it was coupling" — this is the intellectual pivot that makes case studies worth reading. The insight that email notification delays caused fraud detection timeouts is specific and non-obvious. Readers building synchronous call chains will immediately check their own systems.

③ Options considered before the chosen path — "horizontal scaling (4× cost), vendor replacement (18 months), async re-architecture" — showing rejected options is as valuable as showing the chosen one. Every reader evaluating the same problem has the same three options; knowing why you ruled out scaling and vendor replacement tells them whether their ruling should match yours.

Option C ("slow, unreliable, not built for scale") describes the emotional experience of the problem, not the engineering diagnosis. Option D contextualises the problem in "typical growing pains" — which is normalising rather than explaining.

Solution sections in technical case studies must describe the architecture in terms of responsibilities and primitives, document the key design debates, and explain explicit scope exclusions.

Option B does three things that elevate it:

① Describes responsibilities, not just components — "payment authorisation (synchronous, 2s limit)", "downstream processing (async, independent retry)", "compensation (event-triggered reversal)" — describing what each layer is responsible for is more useful to the reader than listing the technologies used. The technologies are means; the responsibilities are the architecture.

② Documents the key design debate — "should fraud scoring remain synchronous? argument for/against" — this is the most valuable writing in any solution section. The decision to split fraud scoring into synchronous rule-check + async ML pass is not obvious, and the reasoning behind it is exactly what the reader needs to make a similar decision. Most case studies omit this because it reveals uncertainty; the best case studies include it because it reveals thinking.

③ Explicitly scopes exclusions and explains why — "we intentionally did not redesign the database schema" with the reason (simultaneous risk too high) — this prevents the most common reader misunderstanding: "why didn't they also fix X?" Naming scope exclusions and providing reasoning demonstrates that you considered them, not that you missed them.

Option A mentions the technologies but describes none of the architecture. "The team worked hard" is not architectural information. Option C includes process details (agile sprints, standups) that are irrelevant to the technical solution. Option D is adjective-heavy and information-free.

Results sections in technical case studies must compare before/after with specific metrics, report what didn't improve as expected, and include cost impact.

Option B is the professional standard for four reasons:

① Before/after for every claim — "8.4s → 1.1s", "4.2% → 0.08%", "45 min manual → automatic" — before/after pairs are the minimum unit of evidence. "Much faster" (Option A) contains no information because the reader cannot evaluate "much" without the baseline.

② Operational metrics alongside performance metrics — on-call pages per week and MTTR are the metrics that translate engineering improvement into team impact. A CTO or engineering manager reading the case study needs this layer; performance metrics alone tell the infrastructure story, not the people story.

③ "What didn't improve as expected" — transaction failure rate improved only 0.3% instead of the expected 1%, and the explanation is honest: the async architecture exposed a coupling that was previously hidden. This is the most sophisticated part of the results section. Publishing the miss, explaining why, and naming the next phase demonstrates engineering maturity and makes the case study credible. Readers know systems don't improve perfectly across all dimensions; admitting where they didn't signals the results section can be trusted.

④ Cost transparency — "$2,800/month for Kafka vs. avoided engineering on-call cost" — any infrastructure change has a cost; publishing it, and comparing it to the benefit, completes the business case. Results sections that omit cost are missing the closing argument.

Option C references "customer satisfaction scores" and "positive feedback" — these are real data points but irrelevant without the baseline. Option D "we recommend a similar approach" is a conclusion, not a result.