ow to think about design patterns &
H
system design — interview-ready guide
reat question. For interviews you need two things at once: (A) a repeatable, structured way to
G
reason aloud, and (B) a toolkit of patterns, trade-offsand optimizations you can cite and apply.
Below I give you both: a shortanswer templateyoucan use in interviews, plus thedesign
building blocksandperformance checklistyou shouldmention.
) Interview-ready framework (what to say,
1
step-by-step)
Follow this script — it keeps you organized and looks professional.
1. Clarify requirements & constraints(1–2 min)
○ A
sk: functional scope, traffic estimates (RPS), storage size, SLAs, expected
growth, read/write ratio, consistency needs, latency targets, budget,
security/compliance.
○ State assumptions explicitly if interviewer doesn’t give numbers.
2. Define core features / APIs / user flows
○ L
ist the main operations (e.g., create user, post message, read feed) and which
are critical/latency-sensitive.
3. High-level architecture (block diagram)
○ D
raw user → CDN → Load Balancer → stateless app servers → cache → DB →
async workers.
○ Explain data flow verbally and map components to responsibilities.
4. Data model & API design
○ S
how simple schemas (tables/documents), important indexes, and major APIs
with responses.
5. Bottlenecks & scaling plan
○ Identify likely bottlenecks (DB, cache miss rate, network) and how to scale them
(sharding, read replicas, caches).
6. Reliability & consistency
○ H
ow you handle failures: retries with backoff, circuit breakers, replication,
graceful degradation.
7. Performance optimizations & trade-offs
○ Mention caching, compression, batching, pagination, async work queues.
8. Non-functional concerns
○ Monitoring/alerts, observability, metrics, security, testing, deployment strategy.
9. Wrap up: trade-offs & alternatives
○ S
ummarize why you chose the approach and what you’d change if constraints
differ.
Keep answers concise. If they want more depth on any block, drill down there next.
) Design patterns & where to use them
2
(practical list)
Mention these patterns andone-sentence use caseforeach:
Client / UI / Frontend patterns
● Lazy loading / Code splitting— reduce initial bundlesize.
● Debounce / Throttle— avoid spiky requests (search,scroll).
● Observer / Pub-Sub— UI events, websockets update flow.
Server / Application patterns
● MVC / Hexagonal (Ports & Adapters)— cleanly separatedomain logic from infra.
● Repository / DAO— data access abstraction for easierswapping DBs.
● Factory / Strategy— pluggable algorithms (e.g., differentauth providers).
● Circuit Breaker & Retry— protect downstream servicesand avoid cascading failures.
● Bulkhead— isolate failures between subsystems (e.g.,payment vs notifications).
● Cache Aside— common caching strategy for reads.
● C
QRS (Command Query Responsibility Segregation)—separate read/write models
for scale.
● Event Sourcing(only when you need auditability orcomplex time travel).
Distributed systems patterns
● Leader election, consensus (Raft/Paxos)— mentionif you need strong coordination.
● Sharding / Partitioning— scale write throughput.
● Message Queue / Worker— decouple synchronous requestfrom heavy processing.
Name a pattern and one concise reason why it fits — interviewers like applied knowledge.
) System-design performance checklist
3
(what to optimize and why)
Front-end (perceived performance)
● Minimize initial payload (code-splitting, tree-shaking).
● Use SSR/SSR-cache or pre-render for first paint (if web).
● Optimize images (responsive sizes, WebP), fonts, and critical CSS.
● Defer non-critical work (lazy load below-the-fold).
● Use Service Worker + caching for offline and fast repeat loads.
● Reduce number of requests (bundle, HTTP/2 multiplexing).
● Use client-side caching & ETags.
Network & transport
● UseCDNfor static assets and edge caching.
● Enable compression (gzip/ Brotli).
● Prefer HTTP/2 or HTTP/3 where possible.
● Keep-alive connections and connection pooling for DB/HTTP clients.
API layer (latency and throughput)
● Keep endpoints skinny (return only needed fields).
● Use pagination & cursors for lists.
● Batch requests where sensible (bulk APIs).
● Use connection pools and keep DB connections healthy.
Caching strategy
● M
ulti-tier caching: CDN (edge) → API gateway cache → in-memory app cache (Redis /
Memcached) → DB.
● C
ache expiry and invalidation strategy — mention cache-aside, TTLs, and soft
invalidation.
● Use consistent hashing for cache cluster scaling.
Database & storage
● C
hoose right DB type: relational (transactions, joins) vs. document/NoSQL (flexible
schema, scale reads).
● Indexes for query patterns (show ability to propose indexes for common queries).
● Read replicas for scaling reads; master for writes + partitioning for write scale.
● Consider columnar stores or OLAP for analytics.
● Use time-series DBs when metrics-heavy.
Asynchrony & background work
● Offload long-running tasks to queues (RabbitMQ, Kafka, SQS).
● Rate-limit and backpressure producers/consumers.
● Use idempotent operations for retries.
Scalability & availability
● Stateless app servers (horizontal scale + autoscaling).
● Load balancer + health checks.
● Multi-AZ / multi-region replication for disaster recovery if needed.
Security & robustness
● Rate limiting, authentication & authorization, input validation.
● TLS everywhere, secret management.
● Use WAF and DDoS protection at the edge.
Observability
● Instrumentation: request latency, error rates, throughput (RPS), resource metrics (CPU,
mem).
● Distributed tracing (open-telemetry), structured logs, alerts & SLO/SLA definitions.
) Sample short answer (how to present
4
this in an interview)
If they ask “Design a scalable file-sharing service” you could reply:
“ First, quick clarifying questions: how many users and average upload size? I’ll
assume 100k daily active users and average file size 5MB for now.
High-level: user → CDN (edge upload/download) → API layer (auth, metadata) →
object storage (S3 or equivalent) → metadata DB (Postgres) → background worker
for virus scan & thumbnail generation via queue.
For performance: offload uploads directly to pre-signed S3 URLs so app servers
don’t handle file bytes, use CDN for downloads, index metadata for common
queries, and use Redis caching for hot file metadata. For scale: use auto-scaling
stateless services, S3 for storage (virtually unlimited), read replicas for Postgres
and partition metadata if writes grow. For reliability: replicate across regions,
provide graceful degradation (serve read-only from cache), and monitor with
metrics and tracing. Trade-offs: direct S3 puts increase complexity on the client; if
we need server-side processing of each file we’d route through app servers and
use a chunked upload approach. That’s the high-level — which part would you like
me to deep-dive into: upload flow, storage model, or scaling strategy?”
oncise, asks clarifying questions, gives architecture, explains optimizations, signals where to
C
dive deeper.
) Quick list of metrics & terms to
5
name-drop (interviewers like this)
● RPS / latency percentiles (p50, p95, p99)
● Throughput (MB/s), QPS, concurrency
● SLO / SLA / error budget
● Cache hit ratio, TTL
● Backpressure, rate limiting
● Eventual vs strong consistency (CAP theorem)
● Idempotency, graceful degradation, circuit breaker
● Autoscaling policy (CPU/RPS based)
Use these when describing trade-offs or SLAs.
) Short checklist to practice before
6
interviews
● P
ractice the 9-step interview framework above on 4 common system-design prompts
(e.g., URL shortener, chat, image upload, newsfeed).
● F
or each, be able to sketch: API, data model, high-level blocks, bottlenecks, one scaling
strategy, and one trade-off alternative.
● T
ime yourself: first 2–3 minutes clarifying + high-level, then 8–10 minutes drilling a
component.
7) Final tips (how to sound confident)
● S
tructure your answer(clarify → high-level → components→ bottlenecks →
trade-offs).
● Be explicit about assumptions.If you guess, say it.
● Offer alternatives(e.g., SQL vs NoSQL) and the trade-offs.
● Q
uantifywhen possible: “assume 1000 RPS, 5% growth monthly” — even rough
numbers help.
● If stuck, suggest a small baseline design and sayhow you’d iterate.
If you want, I can:
● G
ive 3practice promptsand model answers (URL shortener,chat system, newsfeed) so
you can rehearse.
● Or produce a one-page cheat sheet you can review before interviews.
Which would you like next?
ystem Design & Design Patterns —
S
One-Page Interview Cheat Sheet
Use this as your go-to before interviews.Read it,breathe, then speak with structure.
. Answer Framework (use this order — 60–90s
1
high-level, then drill)
1. Clarifyrequirements & constraints (users, RPS, datasize, SLAs).
2. Define core features / APIs(what operations mattermost).
3. H
igh-level architecture(block diagram: client → CDN→ LB → app → cache → DB →
workers).
4. Data model & API examples(sketch key tables/docs+ important indexes).
5. Bottlenecks & scaling(DB, network, caches — how to scale each).
6. Reliability & failure handling(replication, retries,circuit breaker, graceful degradation).
7. Perf optimizations & trade-offs(caching, batching,async, consistency choices).
8. Non-functional & ops(monitoring, metrics, alerts,CI/CD, security).
9. Wrap upwith trade-offs and next steps / deeper dive.
2. Quick Patterns to Name-Drop (one line each)
● Cache-Aside / CDN— reduce read latency for hot data& assets.
● Circuit Breaker / Retry— protect from cascading failures.
● Bulkhead / Rate Limiting— isolate failures, protectresources.
● CQRS— separate read and write models for scale.
● Event Queue (pub/sub)— async decoupling (Kafka/SQS).
● Sharding / Partitioning— scale writes and storage.
● Leader Election / Consensus— coordination when needed(Raft).
● Repository / DAO— abstract DB access for testability.
● Factory / Strategy— runtime pluggable behavior.
. Performance Checklist (say these when asked about
3
optimizations)
Frontend / Perceived perf
● Code-split, lazy load, minimize initial bundle.
● Optimize images (responsive sizes, WebP), critical CSS only.
● Use Service Worker for repeat navigations & offline.
Network
● CDN for static + edge caching. gzip/Brotli + HTTP/2 or HTTP/3.
● Keep-alive, connection pooling.
API & Backend
● Thin payloads, pagination/cursors, batch requests.
● Use Redis / Memcached for low-latency reads.
● DB: proper indexing, read replicas, partitioning for scale.
Async & Background
● Offload heavy tasks to queues; ensure idempotency.
● Use bulk/batched writes where possible.
Caching
● M
ulti-tier (edge → app cache → DB). TTLs, cache invalidation strategy, cache hit ratio
target.
4. Common Trade-Offs to Call Out
● Consistency vs Availability(CAP): choose eventualvs strong depending on UX.
● C
omplexity vs Performance: caching and sharding speedthings up but add
invalidation/operational cost.
● C
lient complexity vs server load: presigned S3 uploads reduce server bandwidth but
complicate client.
● Latency vs Cost: multi-region replication lowers latencybut increases cost.
5. Useful Metrics & Terms (drop these naturally)
● RPS / QPS,p50 / p95 / p99 latency,throughput (MB/s)
● Cache hit ratio,SLO / SLA / error budget,backpressure,idempotency
● Leader election,replication lag,read replicas,shardkey
6. Short Example Pitch (30–45s structure)
“ Assuming X users and Y RPS: user → CDN → LB → stateless app servers →
Redis cache → Postgres (master + read replicas) → object storage (S3) for files.
Background workers (queue) handle thumbnails/processing. Scale: autoscale
stateless servers, add read replicas, shard metadata if writes grow. Reliability:
multi-AZ, retries + circuit breakers, monitor p95/p99. Trade-off: presigned uploads
reduce server bandwidth but require secure client logic.”
7. Quick Drill Prompts (practice)
● Design:URL shortener— focus on unique ID generation,DB schema, scaling.
● Design:Chat system— focus on low latency, pub/sub,message delivery guarantees.
● Design:File upload service— focus on direct uploads,virus scan pipeline, CDN.
8. Interview Delivery Tips
● Alwaysask clarifying Qs(numbers change design).
● State assumptionsexplicitly.
● Start high-level, then ask which part to deep dive.
● Use metrics (p95/p99).
● Be ready to propose an alternative and justify it.
eep this in your head before every system-design question — structure + a few pattern
K
buzzwords + clear trade-offs = great answer. Want 3 worked example answers (URL shortener,
chat app, file upload) to rehearse?