--- title: "34/60 Days System Design Questions" url: https://daily.dev/posts/34-60-days-system-design-questions-w3ohw6r7d source_url: https://daily.dev/posts/34-60-days-system-design-questions-w3ohw6r7d type: freeform source: "Joud Awad" author: "Joud Awad" published: 2026-06-09T16:28:08.743Z updated: 2026-06-09T16:28:49.198Z reading_time: 2 upvotes: 47 comments: 10 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # 34/60 Days System Design Questions **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 47 upvotes · 10 comments ## Summary A system design challenge exploring how to improve an AI triage system's classification accuracy from 71% to 90%+ without changing the model or exceeding inference budget. Four prompt engineering strategies are presented: zero-shot with improved system prompt, few-shot examples, chain-of-thought reasoning, and self-consistency via majority voting across multiple runs. Readers are asked to evaluate the accuracy and cost trade-offs of each approach. ## Content Your AI feature works in the demo. It fails in production 3 weeks later. Nobody touched the model. Nobody changed the code. The only thing that changed: the inputs got messier. Here's the setup: You're at a SaaS company. 50,000 support tickets a week. Your team builds an AI triage system — GPT-4o classifies each ticket into 6 categories (billing, bug, feature request, account access, security, other) so the right team gets it instantly. In dev, it nails 71% accuracy. You need 90%+ to cut manual review. The model is locked. The budget for inference isn't unlimited. You need to close the 19-point gap. Here are your four options: **A) Zero-shot with a better system prompt** — rewrite the instructions, add explicit category definitions, specify edge case rules. No examples. **B) Few-shot examples** — add 3–5 real classified tickets directly in the prompt. One example per category edge case. **C) Chain-of-Thought** — add "think step-by-step before answering" to the prompt. Force the model to reason through the ticket before outputting the category. **D) Self-Consistency** — run each ticket through the model 5 times with temperature=0.7, take the majority vote across outputs. Same model. Same ticket. Four different accuracy + cost profiles. Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments. #30DaysOfSystemDesign #AI #SystemDesign #BackendEngineering ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 4 upvotes > **B — Few-shot Best answer here** > > Accuracy: 88–93%. Cost increase: near-zero. > > > Few-shot shifts the model from _reading rules_ to _pattern-matching against real examples_. Fundamentally stronger signal. > > > The part most teams get wrong: they pick the obvious examples. A crystal-clear billing ticket. A textbook bug report. Those teach the model nothing it didn't already know. > > > You want the _ambiguous_ ones. The ticket that looks like billing but is account access. The feature request that reads like a bug. Those are where the model currently fails — and those are the examples that close the... **@joudawad** · 3 upvotes > **A — Zero-shot with a better system prompt** > > Accuracy ceiling: ~78–82%. > > > This is where every team starts. You iterate the prompt, add category definitions, enumerate edge cases. It feels like progress. And for a while it is. > > > The hard wall: instructions _describe_ categories. They can't _show_ the model where the ambiguous cases land. > > > Real example: you define "billing" as anything about charges or invoices. Then you get this ticket — _"I can't log in and I was charged twice last month."_ Billing? Account access? Both? > > > No amount of rewriting tells the model which bucket that gets. It... **@joudawad** · 3 upvotes > **D — Self-Consistency** > > Accuracy: 93–96%. Cost: 5x. Latency: 5x. > > > Run the same ticket 5–10x at temperature=0.7, take the majority vote. Works because each run samples a slightly different path — noise cancels out across runs. > > > The math is good. The cost is brutal. > > > 50K tickets/week × $0.002 × 5 runs = **$500/week** vs **$100/week** with few-shot. You're paying $400/week extra for a 3–5% gain on the hardest cases. > > > Worth it when being wrong is expensive: fraud detection (a missed flag costs hundreds), medical triage (wrong category = real harm). For support routing, a misclassified... **@joudawad** · 2 upvotes > Also, it would mean a lot to me if you could support my content and stay in touch 🙏 > > - YouTube: [https://www.youtube.com/@system-design-lab](https://www.youtube.com/@system-design-lab) > - LinkedIn: [https://www.linkedin.com/in/joud-awad/](https://www.linkedin.com/in/joud-awad/) > - Medium Blog: [https://joudwawad.medium.com/](https://joudwawad.medium.com/) > - Substack: [https://joudawad.substack.com/](https://joudawad.substack.com/) **@lakshyam03** · 2 upvotes > I have three questions: > > 1. Why does option D give accuracy close to 93-96% as mentioned in your comment? Is there a rationale for why it should improve accuracy, considering all classification runs are independent and don't get any feedback? > 2. For 6 categories, wouldn't we like to have atleast one example and for each of these categories? > 3. Does there exist a better architecture for this task? In this example, it would be the path of least friction and makes sense, but if you had to change the architecture -- like preprocess the ticket first (if it holds some fixed structure), would it... --- [View this post on daily.dev](https://daily.dev/posts/34-60-days-system-design-questions-w3ohw6r7d)