System Design was HARD Until I Learned These 20 Patterns

In Partnership with Tripo AI

Tripo AI Raises Nearly $200M to Advance AI 3D and World Models

Tripo AI builds AI 3D foundation models and world models for high demand 3D workflows across interior design, e commerce, gaming, film, VR/AR, digital twins, robotics, and interactive entertainment.

Used by more than 20 million users worldwide, Tripo AI helps creators, developers, and studios turn ideas into high quality 3D assets faster. With its new world model research initiative, Project Eden, Tripo AI is moving AI 3D beyond single asset generation toward persistent, editable, and interactive worlds.

What you can explore with Tripo AI:

Start creating with Tripo AI → here

I spent the first six months of my system design prep memorizing full architectures. “Design Twitter.” “Design Uber.” “Design YouTube.” I could recite solutions, but when the interviewer changed a single constraint, I was lost.

Then I realized I was studying wrong. Every system design answer is assembled from the same 20 building blocks. Learn the blocks, and you can design anything.

Translates human readable domain names (google.com) into IP addresses (142.250.185.78). Every single request on the internet starts with a DNS lookup. In interviews, DNS matters for global load balancing: you can use DNS to route users to the nearest data center.

Shows up in: Every system design question. Always mention DNS when discussing how users reach your system.

A network of servers distributed globally that caches and serves static content (images, CSS, JS, videos) from locations close to the user. Instead of fetching an image from your server in Virginia, a user in Mumbai gets it from a CDN node in Mumbai. Latency drops from 200ms to 20ms.

Shows up in: Design YouTube, Design Instagram, Design Netflix, any system serving media.

Distributes incoming traffic across multiple servers. Three algorithms cover 90% of cases: Round Robin (rotate evenly), Least Connections (send to the least busy server), and IP Hash (same user always hits the same server).

Shows up in: Every question once you scale beyond one server. The moment you say “horizontal scaling,” a load balancer appears.

A single entry point that sits in front of all your backend services. Handles authentication, rate limiting, request routing, and protocol translation. Think of it as a smart receptionist that checks your badge, finds the right department, and enforces the rules.

Shows up in: Design Uber, any microservices architecture, any system with a public API.

Controls how many requests a user or service can make in a given time window. Protects your system from abuse, DDoS attacks, and runaway clients. Common algorithms: token bucket, sliding window, fixed window.

Shows up in: Design API Rate Limiter (a standalone question), and as a component in almost every other question.

Stateless servers that handle business logic. The key word is stateless: any server can handle any request. Session data lives in a shared cache (Redis), not on the server. This makes horizontal scaling trivial: add more servers behind the load balancer.

Shows up in: Every question. The foundation of any scalable backend.

Breaking a monolith into independent services, each owning its own data and deploying independently. User Service, Order Service, Payment Service. Each team owns one service. The trade off: simpler deployments per service, but network calls replace function calls and debugging becomes distributed.

Shows up in: Design Uber, Design Amazon, any system with multiple teams or domains.

Short lived functions that run on demand. No server management. You pay per execution. Perfect for event driven tasks: “When a user uploads an image, resize it.” Not suitable for long running processes or anything requiring persistent connections.

Shows up in: Design image processing pipelines, webhook handlers, event driven architectures.

Tables with rows and columns. Strict schema. ACID transactions. PostgreSQL and MySQL are the standards. Use SQL when your data has relationships (users have orders, orders have items) and you need strong consistency.

Shows up in: Design Twitter (users, tweets, follows), Design E Commerce (products, orders, payments), most CRUD systems.

Flexible schema. Scales horizontally with ease. Multiple types exist: Document stores (MongoDB: JSON documents), Key value stores (DynamoDB, Redis: simple lookups), Wide column stores (Cassandra: time series, high write throughput), Graph databases (Neo4j: relationships between entities).

NoSQL TypeBest forExampleDocumentFlexible schemas, nested dataMongoDBKey ValueSimple lookups, sessions, cachingDynamoDB, RedisWide ColumnTime series, high write volumeCassandraGraphComplex relationships, social networksNeo4j

Shows up in: Design Chat System (Cassandra), Design Social Graph (Neo4j), Design Config Store (DynamoDB).

Stores unstructured data: images, videos, PDFs, backups. Amazon S3 is the standard. Virtually unlimited capacity, extremely durable (99.999999999% durability), and cheap. Never store large files in a database. Always use object storage.

Shows up in: Design Instagram (photos), Design YouTube (videos), Design Dropbox (files).

Fast, in memory storage (Redis, Memcached) that holds frequently accessed data. A cache hit returns data in under 1ms. A database query takes 10 to 50ms. Cache aside is the default pattern: check cache first, fall back to DB on miss, populate cache for next time.

Shows up in: Every single question. If your design does not mention caching, you are leaving performance on the table.

A specialized data structure optimized for full text search. Elasticsearch is the standard. When a user types “blue running shoes” in a search bar, you cannot SELECT * FROM products WHERE name LIKE '%blue%'. That is too slow. A search index pre processes and inverts the data so queries return in milliseconds.

Shows up in: Design Search Autocomplete, Design E Commerce (product search), Design Logging System (log search).

A buffer between producers and consumers. The producer drops a message into the queue and moves on. The consumer picks it up when ready. Decouples services, absorbs traffic spikes, and enables retry logic. Kafka, RabbitMQ, and SQS are the standards.

QueueBest forKafkaHigh throughput event streaming, log aggregationRabbitMQTask queues, complex routing, request/replySQSSimple cloud native queues, serverless integration

Shows up in: Design Notification System, Design Order Processing, Design Email Service, any async workflow.

A messaging pattern where publishers broadcast events to multiple subscribers without knowing who they are. Different from a queue: a queue delivers a message to ONE consumer. Pub/Sub delivers to ALL subscribers. Google Pub/Sub, Kafka topics, and Redis Pub/Sub are common choices.

Shows up in: Design Real Time Feed, Design Notification System, Design Live Sports Score Updates.

A persistent, bidirectional connection between client and server. Unlike HTTP (request → response → close), WebSockets keep the connection open so the server can push data to the client at any time. Essential for real time features.

Shows up in: Design Chat Application (WhatsApp), Design Live Collaboration (Google Docs), Design Live Dashboard.

Three API communication styles. REST for public APIs (universal, cacheable). GraphQL for complex frontends (client picks the data shape). gRPC for internal service to service calls (binary, fast, streaming). Most modern architectures use all three at different layers.

Shows up in: Every question. Choose the right API style for each communication boundary.

Copying data from a primary database to one or more replicas. The primary handles writes. Replicas handle reads. Since most apps are 90%+ reads, this multiplies your read throughput without touching the write path. If the primary dies, a replica gets promoted.

Shows up in: Any question requiring high availability or read heavy workloads.

Splitting data across multiple database servers. Each shard holds a subset of the data (e.g., users A through M on Shard 1, N through Z on Shard 2). Sharding is the last resort after replication, caching, and query optimization have been exhausted. Choosing the right shard key is critical: a bad key creates hot shards.

Shows up in: Design Twitter (shard by user_id), Design URL Shortener (shard by hash), any system with billions of rows.

Three pillars: Metrics (quantitative measurements like latency, error rate, throughput), Logs (event records for debugging), and Traces (tracking a request across multiple services). Without observability, you are flying blind. Tools: Prometheus + Grafana for metrics, ELK stack for logs, Jaeger or Datadog for traces.

Shows up in: Rarely asked directly, but mentioning it in any answer shows maturity. “I would add distributed tracing to track requests across services” is a staff level signal.

LayerBuilding BlocksInterview SignalTrafficDNS, CDN, Load Balancer, API Gateway, Rate Limiter”I understand how traffic reaches my system”ComputeApp Servers, Microservices, Serverless”I can structure backend logic appropriately”StorageSQL, NoSQL, Blob Storage, Cache, Search Index”I pick the right storage for the right data”CommunicationQueue, Pub/Sub, WebSockets, REST/GraphQL/gRPC”I know how components talk to each other”ReliabilityReplication, Sharding, Monitoring”I build systems that survive failures”

For more visual explanations of system design, DSA patterns, AI in engineering and tech productivity, Subscribe To Grind Engineer! 🚀

Follow me on Youtube · LinkedIn · X · Instagram to stay updated.

See you in the next one!
Signing Off, Scortier