CHAPTER 34
AI Case Studies I: Assistant, Enterprise RAG, Coding Assistant
Three complete designs using the template: requirements, estimation, architecture, deep dives, trade-offs
Source: PDF pp. 91–93
Core PDF content
PDF page 91Design 1: a ChatGPT-style assistant platform p. 91
| Functional requirements | Non-functional requirements and scale |
|---|---|
| - Multi-turn chat with streaming responses - Several models (fast, large, reasoning) selected automatically or by the user - Tools: web search, code execution, file analysis; memory and personalisation | - TTFT < 1-2 s, then smooth streaming (> 20 tokens/s) - 99.9% availability; graceful degradation under GPU shortage - 10 M DAU, ~8 requests/user/day, ~700 input (history truncated or summarised) + ~400 output tokens - Safety, abuse resistance and strict cost control |
- Free and paid tiers with quotas; conversation history across devices
| Quantity | Estimate | Design implication |
|---|---|---|
| Requests | 10 M x 8 = 80 M/day = ~925/s (peak ~3,000/s) | Request rate is modest; tokens are the load |
| Output tokens | 80 M x 400 = 32 B/day = ~370 k tokens/s (peak ~1.1 M/s) | Decode capacity dominates the GPU bill |
| Illustrative GPU need | If one 8-GPU node sustains ~10 k output tokens/s at the latency SLO: 1.1 M / 10 k = ~110 nodes (~900 GPUs) at peak | Placeholder: benchmark your model, context lengths and SLO |
| History storage | 80 M msgs/day x ~2 KB = ~160 GB/day | Sharded document store; tier or expire old chats |
- Context management: history grows each turn. Keep the last N turns verbatim, summarise older ones, store long-term memory as retrievable facts, and attach files via retrieval, to stay within the context budget and cost. Put the stable prefix (system prompt, tools) first so prefix caching hits.
- Streaming: SSE from the inference engine through the router, chat service and gateway; the UI renders tokens as they arrive. Cancel generation immediately when the client disconnects (frees GPU).
- Routing and tiers: a cheap classifier or heuristic selects small vs large vs reasoning model; priority queues give paid users lower queueing delay; under overload, shed free-tier load or degrade to a smaller model rather than fail.
- GPU efficiency: continuous batching, paged KV cache, prefix-aware load balancing (send a conversation to the replica holding its cached prefix), speculative decoding, quantisation, disaggregated prefill/decode for long prompts.
- Capacity and failure: autoscale on queue depth and KV-cache utilisation; keep warm spare replicas because loading weights is slow; multi-region with regional capacity pools; retry idempotently on a different replica when a worker dies mid-stream (resume or restart).
- Safety and abuse: input and output moderation, per-user rate and token limits, bot and scraping detection, tool sandboxing (no ambient credentials), logging with retention and privacy controls.
TRADE-OFF Larger models give better answers but cost more and respond slower. The product decision is a routing policy: which requests deserve the expensive model. Measure quality vs cost per segment and tune with experiments.
Design 2: enterprise document Q&A (permission-aware RAG) p. 92
| Functional requirements | Non-functional requirements and scale |
|---|---|
| - Employees ask questions over company knowledge (Drive, SharePoint, Confluence, Slack, Jira) - Answers cite sources; users can open the original - Respect each user's existing permissions; reflect updates within | - Answer latency < 5 s; high precision, low hallucination - No data leakage between users or tenants (hard requirement) - 50,000 employees; ~20 M documents, ~300 M chunks - Multi-tenant SaaS or single-tenant VPC deployment |
minutes - Feedback and analytics for admins
| Quantity | Estimate | Design implication |
|---|---|---|
| Vectors | 300 M chunks x 1,024 dims x 1 B (8-bit quantised) = ~300 GB (+ index overhead) | Sharded vector index, quantisation; per-tenant namespaces |
| Query load | 50 k users x 5 queries/day = 250 k/day = ~3/s avg (peak ~30/s) | Retrieval and LLM cost dominate, not QPS |
| Ingestion | Initial 20 M docs; ~1 M changes/day | Incremental sync via webhooks/CDC; backfill queue |
- Permissions are the hard part. Mirror source ACLs (users, groups, shares, inheritance) into index metadata; sync permission changes quickly (a revoked user must lose access within minutes). When groups are huge or ACLs complex, resolve at query time against the source ("late binding") for the final candidate set as a safety net.
- Freshness: webhooks and change feeds from each connector; content hash to skip no-ops; delete tombstones propagate to the index; periodic full reconciliation.
- Quality stack: structure-aware parsing (tables, slides, OCR), contextual chunking, hybrid search + cross-encoder reranker, query rewriting using conversation context, source-aware ranking (recency, authority), and "I could not find this in the documents you can access" as a valid answer.
- Evaluation: golden set of real questions with expected source docs; track retrieval recall@k, faithfulness and citation accuracy in CI; thumbs and "report wrong answer" feed the set. Test permissions with adversarial users.
- Cost and scale: quantise vectors, shard by tenant, cache frequent queries and embeddings, use a small model for rewrite/routing and a larger one for final synthesis.
- Security: prompt-injection from documents is a real threat (a wiki page that says "ignore previous instructions"); treat retrieved text as data, never grant tools based on it, and log which chunks influenced each answer for audit.
PDF page 93Design 3: an AI coding assistant (completion + chat + agent) p. 93
| Functional requirements | Non-functional requirements and scale |
|---|---|
| - Inline code completion as the developer types (single and multi-line) - Chat about the codebase; explain, refactor, generate tests - Agent mode: make multi-file changes, run tests, iterate, present a diff - Works across languages and large repositories | - Inline suggestions visible in < 300 ms (otherwise unused) - Code and secrets must be protected; optional no-retention and local index - 1 M developers, ~100 completion requests/developer/hour while active - High acceptance rate, low "annoyance" |
| Quantity | Estimate | Design implication |
|---|---|---|
| Completion requests | 1 M devs x 20% active x 100/h = ~5.5 k/s average, bursty | Needs a small, fast model plus aggressive caching and debouncing |
| Tokens per completion | ~1-2 k context in, ~30-60 out | Prefill-heavy and tiny output: optimise TTFT, prefix cache the file |
| Agent sessions | Long-running; dozens of model calls and tool runs per task | Durable state, sandboxes, cost budgets |
- Fill-in-the-middle (FIM): completion models are trained to predict code between a prefix and a suffix. Context selection (current file around the cursor, imports, definitions of nearby symbols, recently edited files, similar snippets) matters more than model size for relevance.
- Latency engineering: debounce keystrokes, cancel outdated requests, stream partial results, cache the repeated file prefix (prompt caching), use a small quantised model with speculative decoding, place inference near developers, and show suggestions only when confidence is high enough.
- Repository understanding: index the repo with embeddings of chunks plus a symbol/call graph (tree-sitter / language servers) and keyword search (ripgrep). Agents combine semantic search, exact search and file reads; incremental re-indexing on file change; indexes can live locally for privacy.
- Agent mode: plan, edit via diffs (not full-file rewrites), run tests and linters in a sandbox, read failures, iterate within a step budget, show a reviewable diff, require approval for commands that touch the network or delete files.
- Quality and evaluation: offline: pass@k on benchmark tasks and repo-level tasks with tests (SWE-bench-style), regression suites; online: acceptance rate, accepted-characters retained after edit, time saved, latency percentiles, and rate of reverted changes.
- Security and compliance: secret scanning before sending context, exclude files (.env, keys), no training on customer code by default, license-aware filtering of verbatim public code, audit logs; protect against prompt injection in repo files and tool outputs.
Review questions for this chapter have not been written and reviewed yet. The chapter text above is the full source content.
Try it
References
System Design & AI System Design: The Complete Guide — 2026 Edition, pp. 91–93; figures 62, 63, 64.
Tip: use ← and → keys to move between chapters.