Back to Blog
Career13 min readMarch 5, 2026

System Design Interview: 10 Diagrams You Need to Know

The architecture diagrams that come up in every system design interview — load balancers, caches, queues, and beyond.

Why diagrams win interviews

System design interviews test your ability to communicate complex architectures clearly. A well-drawn diagram demonstrates that you can decompose a problem, identify bottlenecks, and make trade-offs — which is exactly what the interviewer is evaluating.

1. Load balancer + web tier

Every system design starts here: clients → DNS → load balancer → application servers. Know the difference between L4 (TCP/UDP) and L7 (HTTP) load balancing. Mention health checks, sticky sessions (and why to avoid them), and horizontal scaling.

2. Database sharding

When a single database can't handle the load, shard by a partition key (user_id, tenant_id). Draw the routing layer that directs queries to the right shard. Discuss trade-offs: cross-shard queries are expensive, rebalancing is painful, and hotspots can negate the benefits.

3. Caching layer

Redis or Memcached between the application and database. Draw cache-aside (lazy loading) vs write-through vs write-behind patterns. Mention cache invalidation strategies, TTL policies, and thundering herd prevention.

4. Message queue / event bus

Kafka, SQS, or RabbitMQ for async processing. Draw producers → topic/queue → consumers. Explain how queues provide backpressure, enable retry logic, and decouple services. Mention dead-letter queues for failed messages.

5. CDN and edge caching

CloudFront, Fastly, or Cloudflare for static assets and API response caching. Draw the CDN in front of the load balancer. Discuss cache-control headers, origin shielding, and purge strategies.

Build your architecture diagram now

Datadef generates professional diagrams with AI — 2,000+ cloud icons, column-level data lineage, and an MCP server your coding agent can drive.

6. Microservices decomposition

Break the monolith into bounded contexts. Draw service boundaries, API gateways, and inter-service communication (sync REST/gRPC or async events). Show the database-per-service pattern.

7. Search infrastructure

Elasticsearch or Solr for full-text search. Draw: source DB → CDC/ETL → search index → search API. Mention indexing strategies, relevance tuning, and how to handle schema changes.

8. Notification system

Email, push, SMS, in-app notifications. Draw: event trigger → notification service → per-channel workers → delivery APIs (SendGrid, FCM, Twilio). Include retry logic and preference management.

9. Rate limiter

Token bucket or sliding window at the API gateway. Draw: request → rate limiter (Redis counter) → proceed or 429. Discuss distributed rate limiting challenges across multiple gateway instances.

10. Data pipeline

Ingestion → processing → storage → serving. Draw: Kafka/Kinesis → Spark/Flink → data lake/warehouse → BI tools. Distinguish batch vs streaming paths. Mention schema registry and data quality checks.

Practice with real diagrams

Reading about architectures is different from drawing them under time pressure. Practice by diagramming systems you use daily — your company's architecture, Twitter's timeline, or Uber's dispatch system. Datadef's AI can generate starting-point diagrams that you can customize and learn from.