{"title":"Must-Know Technologies for System Design Interviews","description":"","content":"Understanding system design concepts is essential. But you also need to know the technologies that implement those concepts.\n\nWhen you say \"I'd use a cache here,\" the interviewer might ask \"Which caching solution would you choose and why?\" Knowing the difference between Redis and Memcached, or when to use Kafka versus RabbitMQ, demonstrates real-world knowledge.\n\nThe good news: you don't need deep expertise in dozens of technologies. In practice, the same 15-20 tools show up in most system design discussions. Know these well, understand their trade-offs, and you'll be equipped for any interview.\n\nThis chapter covers the technologies that matter most, organized by category. For each one, I'll explain what it does, when to use it, and how to talk about it in an interview.\n\n---\n\n# Technology Landscape\n\nBefore diving into specifics, here's the mental map. Every system design essentially combines technologies from these categories:\n\n\n```mermaid\nflowchart LR\n subgraph Data[\"Data Layer\"]\n direction TB\n A[(PostgreSQL
MySQL)]:::primary\n B[(MongoDB
Cassandra
DynamoDB)]:::orange\n end\n\n subgraph Speed[\"Speed Layer\"]\n direction TB\n C[Redis]:::green\n D[Memcached]:::green\n E[CDN]:::green\n end\n\n subgraph Async[\"Async Layer\"]\n direction TB\n F[Kafka]:::purple\n G[RabbitMQ]:::purple\n H[SQS]:::purple\n end\n\n subgraph Support[\"Supporting Services\"]\n direction LR\n I[Elasticsearch]:::pink\n J[S3]:::teal\n K[Load Balancer]:::teal\n end\n\n Data --> Speed\n Data --> Async\n Speed --> Support\n Async --> Support\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n classDef pink fill:#f783ac,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThink of it this way: your **data layer** is the source of truth. Your **speed layer** makes things fast. Your **async layer** decouples and buffers. And **supporting services** handle specialized needs like search, file storage, and traffic distribution.\n\nLet's explore each category.\n\n---\n\n# 1. Relational Databases\n\nRelational databases are the workhorses of most applications. When your data has clear structure, relationships matter, and you need transactions that actually work, this is where you start.\n\n## PostgreSQL\n\n\n\n\nIf I had to pick one database to recommend for most applications, it would be PostgreSQL. It's the Swiss Army knife of databases: powerful enough for complex analytics, reliable enough for financial transactions, and flexible enough to handle JSON when you need it.\n\n#### **What makes PostgreSQL stand out:**\n\nPostgreSQL does everything a relational database should do, and then some. Full ACID compliance means your transactions actually behave correctly. MVCC (Multi-Version Concurrency Control) means readers don't block writers. But where PostgreSQL really shines is in its advanced features:\n\n- **Rich data types:** Native support for JSON, arrays, and even custom types. Need to store a user's preferences as JSON while keeping their core profile relational? PostgreSQL handles both.\n- **Powerful indexing:** Beyond basic B-trees, you get GIN indexes for full-text search and array containment, GiST indexes for geometric data, and partial indexes for when you only care about a subset of rows.\n- **Extensibility:** PostGIS turns PostgreSQL into a geospatial database. TimescaleDB turns it into a time-series database. The extension ecosystem is massive.\n\n#### **Reach for PostgreSQL when:**\n\n- Your data has relationships and you need JOINs\n- Transactions must be reliable (e-commerce, banking, inventory)\n- You need complex queries or reporting\n- You want one database that can handle multiple data patterns\n\n#### **Think twice when:**\n\n- You need to scale writes to millions per second (sharding PostgreSQL is possible but painful)\n- Your access pattern is purely key-value lookups at massive scale\n- You need linear horizontal scaling as a primary feature\n\n\n> **DISCUSSION**\n>\n> **In interviews:** PostgreSQL is the safe default. When the interviewer asks about your database choice for structured data, start here. You can always explain when you'd move to NoSQL, but PostgreSQL handles more use cases than most people realize.\n\n\n---\n\n## MySQL\n\n\n\n\nMySQL is everywhere. It powers much of the web, from WordPress blogs to major internet companies. While PostgreSQL is feature-rich, MySQL is battle-tested and simple.\n\n#### **Why MySQL still matters:**\n\nMySQL's strength is its simplicity and proven track record. The InnoDB storage engine provides solid ACID transactions. Read replicas are straightforward to set up. The ecosystem is enormous: every language has mature MySQL drivers, every cloud offers managed MySQL, and every ops team knows how to run it.\n\nFor read-heavy web applications with straightforward data patterns, MySQL just works. It's not trying to be everything. It's trying to be a reliable, fast relational database, and it succeeds at that.\n\n#### **MySQL vs PostgreSQL:**\n\n\n| Dimension | MySQL | PostgreSQL |\n|--------|-------|------------|\n| Simple reads | Faster | Slightly slower |\n| Complex queries | Limited optimizer | Sophisticated optimizer |\n| JSON support | Functional | First-class |\n| Replication | Simple, mature | More flexible, more complex |\n| Extensions | Limited | Extensive ecosystem |\n| Learning curve | Gentler | Steeper |\n\n\n#### **Which to choose?**\n\nHere's my honest take: for new projects, I lean toward PostgreSQL. Its feature set is broader, and you're less likely to outgrow it. But MySQL is a perfectly valid choice, especially if your team knows it well, your use case is straightforward, or you're working with existing MySQL infrastructure.\n\nIn interviews, either is fine. What matters is that you can explain your reasoning. \"I'd use MySQL because this is a read-heavy workload with simple queries, and our team has strong MySQL experience\" is a good answer.\n\n---\n\n# 2. NoSQL Databases\n\nNoSQL is a broad category, and \"NoSQL\" alone doesn't tell you much. The real question is: what type of NoSQL? Document stores, wide-column stores, and key-value stores solve different problems. \n\nUnderstanding which to use when is what separates informed technology choices from buzzword bingo.\n\n## MongoDB\n\n\n\n\nMongoDB is what most people think of when they hear \"NoSQL.\" It stores data as JSON-like documents, making it natural for applications that already think in JSON.\n\n#### **Why MongoDB works:**\n\nThe document model is intuitive. A user profile isn't just a row in a table. It's a document with nested addresses, preferences, and order history. In a relational database, that's multiple tables and JOINs. In MongoDB, it's one document you read in a single query.\n\n\n```mermaid\nflowchart LR\n A[Application]:::primary --> B[MongoDB Router]:::orange\n B --> C[(Shard 1)]:::green\n B --> D[(Shard 2)]:::green\n B --> E[(Shard 3)]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nMongoDB shards automatically by a shard key you choose. Each shard is itself a replica set for high availability. This gives you horizontal scaling with automatic failover.\n\n#### **MongoDB shines when:**\n\n- Your data is naturally document-shaped (articles, products, user profiles)\n- Schema evolves frequently (startup environment, rapid iteration)\n- You need horizontal scaling without giving up rich queries\n- Your access patterns read/write complete documents\n\n#### **MongoDB struggles when:**\n\n- You have truly relational data with complex cross-document relationships\n- You need multi-document transactions constantly (MongoDB supports them, but they're expensive)\n- Strong consistency is more important than availability\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> MongoDB is a good choice for content management systems, product catalogs, and user profiles. Mention it when you see document-shaped data that doesn't have complex relationships.\n\n\n---\n\n## Cassandra\n\n\n\n\nCassandra is built for one thing: massive scale with high availability. If you need to handle millions of writes per second across multiple data centers with no single point of failure, Cassandra is purpose-built for that.\n\n#### **Why Cassandra exists:**\n\nCassandra was born at Facebook to solve their inbox search problem, then open-sourced and adopted by companies like Netflix, Apple, and Instagram. It's designed around the assumption that at massive scale, nodes will fail constantly, and the system must keep running regardless.\n\nEvery node is equal. There's no master. Data is automatically distributed using consistent hashing, and you can tune how many nodes must acknowledge a write (consistency level).\n\nNeed strong consistency? Require a quorum. Need maximum availability? Accept a single acknowledgment.\n\n#### **Cassandra is the right choice when:**\n\n- You have a write-heavy workload (Cassandra excels at writes)\n- You're dealing with time-series data (logs, metrics, IoT sensor data)\n- You need multi-region deployment with local writes\n- Your scale is truly massive (petabytes of data, millions of operations per second)\n\n#### **Cassandra is the wrong choice when:**\n\n- You need complex queries with JOINs (Cassandra doesn't support them)\n- Your data model requires frequent updates to existing rows (deletes and updates create tombstones)\n- You need strong consistency as the default (Cassandra favors availability)\n- Your dataset is small (Cassandra's overhead isn't worth it for modest scale)\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> Mention Cassandra specifically for time-series data, logging systems, or IoT platforms. It's also a strong choice for anything requiring multi-region writes with high availability.\n\n\n---\n\n## DynamoDB\n\n\n\n\nDynamoDB is AWS's fully managed NoSQL offering. You don't manage servers, replication, or scaling. You create a table, specify your capacity (or let it auto-scale), and AWS handles everything else.\n\n#### **The DynamoDB proposition:**\n\nDynamoDB trades flexibility for operational simplicity. You get single-digit millisecond latency at any scale, automatic replication across availability zones, and zero infrastructure to manage. The cost is that you're locked into AWS and must design your data model around DynamoDB's constraints.\n\nThose constraints are significant. DynamoDB is essentially a key-value store with some document features. You have a partition key (and optionally a sort key), and queries are fast only when you know the keys. \n\nWant to query by an arbitrary field? You need a secondary index. Want complex aggregations? You're better off with something else.\n\n#### **DynamoDB makes sense when:**\n\n- You're building on AWS and want zero database ops\n- Your access patterns are key-based (get user by ID, get orders by user_id + date)\n- You need predictable latency regardless of scale\n- Session storage, shopping carts, user preferences, gaming leaderboards\n\n#### **DynamoDB doesn't make sense when:**\n\n- You need complex queries or ad-hoc analytics\n- Vendor lock-in is a concern\n- Your access patterns aren't well-defined upfront (DynamoDB requires you to design for your queries)\n- Cost predictability matters more than ops simplicity (DynamoDB pricing can surprise you)\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> Mention DynamoDB for serverless architectures or when operational simplicity is paramount. It's a natural fit for AWS Lambda-based systems and mobile app backends.\n\n\n## Choosing Between NoSQL Databases\n\nHere's a decision framework:\n\n\n```mermaid\nflowchart TD\n A[Need NoSQL?]:::primary --> B{What's the data shape?}\n B -->|Documents with queries| C[MongoDB]:::orange\n B -->|Key-value lookups| D{Managed or self-hosted?}\n B -->|Time-series / Write-heavy| E[Cassandra]:::green\n\n D -->|Managed on AWS| F[DynamoDB]:::purple\n D -->|Self-hosted / Multi-cloud| G[Redis / Cassandra]:::purple\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\n\n| Database | Best For | Avoid When |\n|----------|----------|------------|\n| **MongoDB** | Documents, evolving schemas, rich queries | Complex transactions, strict consistency |\n| **Cassandra** | Write-heavy, time-series, multi-region | Ad-hoc queries, small datasets |\n| **DynamoDB** | Serverless, AWS-native, zero-ops | Vendor lock-in concerns, complex queries |\n\n\n---\n\n# 3. Caching Technologies\n\nCaching is how you make slow things fast. Your database might take 50ms to answer a query. Redis answers in under a millisecond. At thousands of requests per second, that difference is the gap between a responsive application and a frustrating one.\n\n## Redis\n\n\n\n\nRedis is the caching technology you'll reach for most often. It's technically an \"in-memory data structure store,\" but that undersells it. Redis is a Swiss Army knife that handles caching, session storage, rate limiting, leaderboards, pub/sub messaging, and more.\n\n#### **Why Redis dominates:**\n\nRedis isn't just fast. It's fast AND versatile. While a simple cache stores strings, Redis gives you:\n\n\n```mermaid\nflowchart TD\n A[Application]:::primary --> B{Redis}:::orange\n B --> C[Strings: Session data]:::green\n B --> D[Lists: Recent items]:::green\n B --> E[Sorted Sets: Leaderboards]:::green\n B --> F[Hashes: User profiles]:::green\n B --> G[Sets: Tags, unique items]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nEach data structure solves specific problems elegantly:\n\n- **Sorted Sets** are perfect for leaderboards. Store user scores, and Redis keeps them sorted automatically. Getting the top 100? One command.\n- **Sets** give you O(1) membership tests. Perfect for \"has this user already voted?\" checks.\n- **Hashes** let you store objects without serialization overhead. Update one field without reading/writing the whole object.\n- **Streams** (newer addition) support event streaming with consumer groups, similar to Kafka but simpler.\n\nRedis also supports persistence (RDB snapshots, append-only log), replication (master-replica), and clustering (sharding across nodes). It's not just a cache; it can be your primary data store for the right use cases.\n\n#### **Redis is the default choice for:**\n\n- Caching database queries\n- Session storage\n- Rate limiting (using sorted sets or Lua scripts)\n- Leaderboards and rankings\n- Real-time counters and analytics\n- Distributed locks\n- Pub/sub messaging (simple cases)\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> When you say \"cache,\" interviewers expect you to say \"Redis.\" But go further. Mention specific data structures. \"I'd use a Redis sorted set for the leaderboard because it automatically maintains order and supports efficient range queries\" shows depth.\n\n\n---\n\n## Memcached\n\n\n\n\nMemcached is the simpler, older alternative to Redis. It does one thing: fast key-value caching. No data structures, no persistence, no pub/sub. Just keys and values, extremely fast.\n\n#### **When would you pick Memcached over Redis?**\n\nIn practice, Redis is almost always the better choice. But Memcached still has its place:\n\n- **Multi-threaded:** Memcached uses multiple threads, so it can utilize multiple CPU cores directly. Redis is single-threaded (though Redis 6+ has I/O threading). For pure caching with massive throughput, Memcached can be more efficient.\n- **Memory efficiency:** Memcached has lower memory overhead per key. If you're storing billions of small values and every byte matters, Memcached wins.\n- **Simplicity:** Less can go wrong. Memcached is just a cache. It doesn't try to be a database or message broker.\n\n#### **Redis vs Memcached at a glance:**\n\n\n| Aspect | Redis | Memcached |\n|--------|-------|-----------|\n| Data structures | Rich (lists, sets, hashes, sorted sets) | Key-value only |\n| Persistence | Yes (RDB, AOF) | No |\n| Replication | Yes | No |\n| Clustering | Yes | Client-side sharding |\n| Threading | Single-threaded core | Multi-threaded |\n| Memory overhead | Higher | Lower |\n| Use cases | Caching + more | Pure caching |\n\n\n**The honest recommendation:** Start with Redis. It does everything Memcached does plus much more. Only consider Memcached if you have a specific performance reason and don't need Redis's features.\n\n---\n\n# 4. Message Queues and Streaming\n\nThis category often confuses candidates because there are two fundamentally different models: **message queues** (work distribution) and **event streaming** (event logs). Kafka and RabbitMQ look similar at first glance, but they solve different problems.\n\n## Apache Kafka\n\n\n\n\nKafka isn't really a message queue. It's a distributed commit log. Messages are written to an append-only log, and consumers read from that log at their own pace. Messages aren't deleted when consumed; they stay in the log until they age out.\n\n#### **Why this matters:**\n\nThis log-based model enables powerful patterns:\n\n- **Replay:** A new consumer can start from the beginning and process all historical events.\n- **Multiple consumers:** Different consumer groups read the same topic independently. The analytics team and the billing team can both process orders.\n- **Event sourcing:** The log becomes the source of truth. You can reconstruct state by replaying events.\n\n\n```mermaid\nflowchart LR\n A[Producers]:::primary --> B[Kafka Cluster]:::orange\n B --> C[Topic: Orders]:::green\n B --> D[Topic: Events]:::green\n C --> E[Consumer Group 1]:::purple\n C --> F[Consumer Group 2]:::purple\n D --> G[Consumer Group 3]:::purple\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\n#### **Kafka's architecture:**\n\nTopics are divided into **partitions** for parallelism. Each partition is an ordered log. Within a **consumer group**, each partition is consumed by exactly one consumer, allowing parallel processing while maintaining order within a partition.\n\n\n```mermaid\nflowchart LR\n subgraph Topic[\"Topic: Orders\"]\n P0[Partition 0]:::primary\n P1[Partition 1]:::primary\n P2[Partition 2]:::primary\n end\n\n subgraph CG[\"Consumer Group\"]\n C0[Consumer 0]:::green\n C1[Consumer 1]:::green\n C2[Consumer 2]:::green\n end\n\n P0 --> C0\n P1 --> C1\n P2 --> C2\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n#### **Kafka is the right choice when:**\n\n- You need event streaming or event sourcing\n- Multiple systems need to react to the same events\n- You need message replay (auditing, debugging, rebuilding state)\n- Throughput requirements are massive (millions of events per second)\n- You're building real-time data pipelines\n\n#### **Kafka is overkill when:**\n\n- You just need a simple task queue (use RabbitMQ or SQS)\n- Message volume is low\n- You don't need replay or multiple consumer groups\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> Mention Kafka for event-driven architectures, analytics pipelines, and activity feeds. Be ready to explain partitions and consumer groups.\n\n\n---\n\n## RabbitMQ\n\n\n\n\nRabbitMQ is a traditional message broker. Unlike Kafka's log-based model, RabbitMQ is designed for task distribution: send a message, exactly one consumer processes it, message is deleted.\n\n#### **When RabbitMQ shines:**\n\nRabbitMQ excels at work distribution. You have tasks (resize images, send emails, process payments), and you want to distribute them across workers. RabbitMQ handles the queuing, acknowledgments, retries, and dead-letter handling.\n\nIt also supports sophisticated routing. With exchanges and bindings, you can route messages based on patterns, headers, or topics. Need to send order messages to both the billing queue and the shipping queue? RabbitMQ handles that elegantly.\n\n#### **RabbitMQ vs Kafka:**\n\n\n| Aspect | RabbitMQ | Kafka |\n|--------|----------|-------|\n| Mental model | Smart broker, simple consumers | Dumb broker, smart consumers |\n| Message fate | Deleted after acknowledgment | Retained in log |\n| Multiple consumers | Competing (one wins) | Each group gets all messages |\n| Ordering | Per queue | Per partition |\n| Replay | No | Yes |\n| Routing | Rich (exchanges, bindings) | Simple (topics) |\n| Best for | Task queues, RPC | Event streaming, logs |\n\n\n**The simple rule:** If you need work distribution (one message = one task for one worker), use RabbitMQ. If you need event streaming (one event potentially processed by many systems), use Kafka.\n\n---\n\n## Amazon SQS\n\n\n\n\nSQS is AWS's managed queue service. It's the simplest option if you're on AWS and just need a reliable queue without managing infrastructure.\n\n#### **Why SQS makes sense:**\n\nZero ops. No servers to manage, no clusters to configure, no ZooKeeper to babysit. You create a queue, send messages, receive messages. AWS handles availability, durability, and scaling.\n\nSQS offers two queue types:\n\n- **Standard queues:** Maximum throughput, best-effort ordering, at-least-once delivery\n- **FIFO queues:** Exactly-once processing, strict ordering, lower throughput (3,000 messages/second with batching)\n\n#### **SQS is the right choice when:**\n\n- You're building on AWS and want zero infrastructure management\n- Your queuing needs are straightforward (no complex routing)\n- You value simplicity over control\n- FIFO queues meet your ordering needs\n\n#### **SQS is limiting when:**\n\n- You need complex routing (RabbitMQ is better)\n- You need message replay (Kafka is better)\n- Multi-cloud is a requirement\n\n#### **Choosing between message technologies:**\n\n\n| Need | Technology |\n|------|------------|\n| Event streaming, replay, multiple consumers | Kafka |\n| Task distribution, complex routing | RabbitMQ |\n| Simple queuing on AWS, zero ops | SQS |\n| Simple queuing on GCP | Cloud Pub/Sub |\n\n\n---\n\n# 5. Search Technologies\n\nWhen someone types \"blue running shoes size 10\" into a search box, your relational database isn't going to cut it. Full-text search requires specialized technology that understands relevance, typos, synonyms, and ranking.\n\n## Elasticsearch\n\n\n\n\nElasticsearch is the dominant player in search. Built on Apache Lucene, it provides full-text search, analytics, and a powerful query language, all accessible via a REST API.\n\n#### **Why you need Elasticsearch:**\n\nYour PostgreSQL database can do basic search with LIKE queries, but it struggles with:\n\n- Relevance ranking (which results are most relevant?)\n- Fuzzy matching (user types \"shoees\" but means \"shoes\")\n- Faceted search (filter by brand, price range, size simultaneously)\n- Auto-complete (suggest \"running shoes\" as user types \"run\")\n- Synonyms (searching \"laptop\" should find \"notebook\")\n\nElasticsearch handles all of this natively.\n\n\n```mermaid\nflowchart LR\n subgraph Primary[\"Primary Database\"]\n DB[(PostgreSQL)]:::primary\n end\n\n subgraph Search[\"Search Layer\"]\n ES[Elasticsearch]:::orange\n end\n\n subgraph UI[\"User Interfaces\"]\n S1[Product Search]:::green\n S2[Log Dashboard]:::green\n S3[Analytics]:::green\n end\n\n DB -->|\"Sync data\"| ES\n ES --> S1\n ES --> S2\n ES --> S3\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n**The typical pattern:** Your primary database (PostgreSQL, MongoDB) is the source of truth. You sync data to Elasticsearch for search. Users search against Elasticsearch, then fetch full records from the primary database.\n\n#### **Common Elasticsearch use cases:**\n\n- **Product search:** E-commerce sites use Elasticsearch for search with filters, facets, and ranking.\n- **Log analytics:** The ELK stack (Elasticsearch, Logstash, Kibana) is the standard for aggregating and searching application logs.\n- **Application search:** Any search box in your application probably should use Elasticsearch.\n- **Auto-complete:** Type-ahead suggestions with fuzzy matching.\n\n#### **Elasticsearch considerations:**\n\nElasticsearch is **not** a primary database. It sacrifices durability and consistency for search performance. Always use it alongside a primary data store.\n\nIt also has a learning curve. The query DSL is powerful but complex. Indexing strategies, mapping types, and shard configuration require thought.\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> Mention Elasticsearch whenever search comes up: product catalogs, autocomplete, log analytics. Note that you'd use it alongside a primary database, not as a replacement.\n\n\n---\n\n# 6. Object Storage\n\nYour database stores structured data. But what about profile pictures, uploaded documents, video files, and backups? That's where object storage comes in.\n\n## Amazon S3\n\n\n\n\nS3 has become synonymous with object storage. It's the default answer when someone asks \"where do we store files?\" in any cloud architecture.\n\n#### **Why S3 dominates:**\n\nS3 offers effectively unlimited storage with remarkable durability: 99.999999999% (11 nines). That's designed to lose less than one object per 10 million objects over 10,000 years. For practical purposes, data in S3 doesn't disappear.\n\n\n```mermaid\nflowchart LR\n subgraph Upload[\"Uploads\"]\n U1[User Images]:::primary\n U2[Documents]:::primary\n U3[Videos]:::primary\n end\n\n subgraph S3[\"S3 Bucket\"]\n B[Object Storage]:::orange\n end\n\n subgraph Serve[\"Serving\"]\n CDN[CloudFront CDN]:::green\n Direct[Direct Access]:::green\n end\n\n Upload --> S3\n S3 --> Serve\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n#### **S3 storage classes save money:**\n\nNot all data is accessed equally. S3 offers storage classes that trade access speed for cost:\n\n\n| Storage Class | Access Pattern | Relative Cost |\n|--------------|----------------|---------------|\n| Standard | Frequent access | $$$$ |\n| Intelligent-Tiering | Unknown/changing patterns | $$$ (auto-moves) |\n| Standard-IA | Infrequent access | $$ |\n| Glacier Instant | Archive, instant retrieval | $ |\n| Glacier Deep Archive | Archive, hours to retrieve | ¢ |\n\n\n**Lifecycle policies** automate transitions. For example: after 30 days, move to IA. After 90 days, move to Glacier. After 7 years, delete.\n\n#### **Common S3 patterns:**\n\n- **User uploads:** Profile pictures, documents, attachments. Generate pre-signed URLs so users upload directly to S3, bypassing your servers.\n- **Static assets:** Host your website's images, CSS, and JavaScript in S3, served via CloudFront.\n- **Backups:** Database dumps, application backups, disaster recovery.\n- **Data lakes:** Raw data storage for analytics pipelines.\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> S3 is the default for any file storage. Mention CDN integration for serving user-facing content and lifecycle policies for cost optimization.\n\n\n---\n\n## HDFS (Hadoop Distributed File System)\n\nHDFS is specialized for big data. If you're processing terabytes or petabytes with Hadoop, Spark, or similar frameworks, HDFS is purpose-built for that.\n\nUnlike S3 (which is accessed over HTTP), HDFS provides high-throughput access for batch processing workloads. It shines when you need to process massive files with frameworks that expect a distributed filesystem.\n\n**When to mention HDFS in interviews:** Big data pipelines, batch processing at massive scale, data warehousing. For general file storage, S3 is the better answer.\n\n---\n\n# 7. Load Balancers\n\nWhen you have multiple servers, you need something to distribute traffic between them. That's your load balancer. But there's more to the choice than just \"use a load balancer.\"\n\n## Layer 4 vs Layer 7 Load Balancing\n\nThe key distinction is what layer of the network stack the load balancer understands:\n\n\n```mermaid\nflowchart TD\n subgraph L4[\"Layer 4 (Transport)\"]\n direction LR\n C1[Client]:::primary --> LB1[NLB]:::orange\n LB1 --> S1[Server]:::green\n LB1 --> S2[Server]:::green\n Note1[\"Routes by IP + Port
Doesn't inspect content
Ultra-fast\"]\n end\n\n subgraph L7[\"Layer 7 (Application)\"]\n direction LR\n C2[Client]:::primary --> LB2[ALB]:::orange\n LB2 -->|\"/api/*\"| S3[API Servers]:::green\n LB2 -->|\"/static/*\"| S4[Static Servers]:::green\n Note2[\"Routes by URL, headers
Inspects HTTP
More flexible\"]\n end\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n**Layer 4 (NLB, HAProxy in TCP mode):** Routes based on IP address and port. Doesn't understand HTTP. Extremely fast, handles millions of connections. Use for non-HTTP protocols (databases, game servers) or when you need maximum performance.\n\n**Layer 7 (ALB, Nginx, HAProxy in HTTP mode):** Understands HTTP. Can route based on URL paths, headers, or cookies. Can do SSL termination, add headers, rewrite URLs. More flexible but slightly slower.\n\n## Nginx\n\n\n\n\nNginx is the workhorse for many organizations. It's a web server, reverse proxy, and load balancer in one package.\n\n#### **Nginx is the go-to when you need:**\n\n- HTTP load balancing with flexible routing\n- SSL termination\n- Static file serving\n- Rate limiting\n- Caching at the edge\n- Custom request/response manipulation\n\nFor simpler setups or when you want full control, Nginx is often the answer.\n\n## Cloud Load Balancers\n\nIf you're on AWS, GCP, or Azure, their managed load balancers are often the simplest choice:\n\n\n| Cloud | Layer 7 | Layer 4 |\n|-------|---------|---------|\n| AWS | ALB (Application LB) | NLB (Network LB) |\n| GCP | HTTP(S) Load Balancing | TCP/UDP Load Balancing |\n| Azure | Application Gateway | Azure Load Balancer |\n\n\n---\n\n# 8. CDN (Content Delivery Network)\n\nA CDN caches your content on servers distributed globally. Instead of every user hitting your origin in Virginia, users hit the nearest edge location, which might be in their city.\n\n### Why CDN Matters\n\nThe speed of light is fixed. A user in Tokyo requesting data from a server in New York has a minimum ~100ms network latency. There's no software optimization that can fix physics.\n\nA CDN puts cached copies of your content on edge servers worldwide. Now that Tokyo user hits a Tokyo edge server with ~10ms latency.\n\n\n```mermaid\nflowchart LR\n subgraph Users[\"Users Worldwide\"]\n U1[Tokyo User]:::primary\n U2[London User]:::primary\n U3[NYC User]:::primary\n end\n\n subgraph CDN[\"CDN Edge Locations\"]\n E1[Tokyo Edge]:::green\n E2[London Edge]:::green\n E3[NYC Edge]:::green\n end\n\n U1 --> E1\n U2 --> E2\n U3 --> E3\n\n E1 --> Origin[Origin Server]:::orange\n E2 --> Origin\n E3 --> Origin\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n## CloudFront vs Cloudflare\n\n**CloudFront** is AWS's CDN. If you're on AWS, it integrates seamlessly with S3, ALB, and other AWS services. Lambda@Edge lets you run code at edge locations.\n\n**Cloudflare** is a CDN-plus-more. Beyond caching, it provides DDoS protection, a Web Application Firewall (WAF), DNS services, and Workers for edge computing. Many companies use Cloudflare even if they're on AWS.\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> Mention CDN whenever you're serving static content to a global audience. Pair S3 with CloudFront for static assets. Mention DDoS protection as a side benefit.\n\n\n---\n\n# 9. Container Orchestration\n\nContainers have become the standard way to package and deploy applications. But running containers at scale requires orchestration: scheduling, scaling, healing, and networking. That's where Kubernetes comes in.\n\n## Docker (The Container Runtime)\n\nDocker packages your application and its dependencies into a container, which runs consistently across environments. No more \"it works on my machine\" problems.\n\nYou don't need deep Docker knowledge for system design interviews, but understand the basics:\n\n- **Image:** A snapshot of your application plus dependencies\n- **Container:** A running instance of an image\n- **Registry:** Where images are stored (Docker Hub, ECR, GCR)\n\n## Kubernetes (The Orchestrator)\n\nKubernetes (K8s) manages containerized applications across a cluster of machines. It handles the operational concerns that become critical at scale.\n\n\n```mermaid\nflowchart TD\n A[Kubernetes Cluster]:::primary\n A --> B[Node 1]:::orange\n A --> C[Node 2]:::orange\n A --> D[Node 3]:::orange\n\n B --> E[Pod]:::green\n B --> F[Pod]:::green\n C --> G[Pod]:::green\n C --> H[Pod]:::green\n D --> I[Pod]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n#### **What Kubernetes gives you:**\n\n- **Scheduling:** Kubernetes decides which node runs each container based on resource requirements.\n- **Scaling:** Define desired replicas, and Kubernetes maintains that count. Add auto-scaling based on CPU, memory, or custom metrics.\n- **Self-healing:** If a container dies, Kubernetes restarts it. If a node fails, Kubernetes reschedules its workloads elsewhere.\n- **Service discovery:** Services get DNS names. Pods find each other without hardcoded IPs.\n- **Rolling updates:** Deploy new versions with zero downtime. Kubernetes gradually replaces old pods with new ones.\n\n#### **Key concepts to know:**\n\n- **Pod:** Smallest unit. Usually one container, sometimes tightly coupled containers.\n- **Deployment:** Declares desired state (image, replicas). Kubernetes makes reality match.\n- **Service:** Stable network endpoint for a set of pods.\n- **Ingress:** Routes external HTTP traffic to services.\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> You don't need to know Kubernetes internals for most system design interviews. Knowing that \"we'd deploy this on Kubernetes for scaling, self-healing, and zero-downtime deployments\" is usually enough. Go deeper only if specifically asked.\n\n\n---\n\n# 10. Monitoring and Observability\n\nYou can't fix what you can't see. In production, observability is how you understand what your system is actually doing: is it healthy, is it fast enough, and when something breaks, why?\n\n### The Three Pillars\n\nModern observability combines three types of data:\n\n\n```mermaid\nflowchart LR\n subgraph Observability\n M[Metrics]:::primary\n L[Logs]:::orange\n T[Traces]:::green\n end\n\n M --> M1[\"CPU, memory, request rate
Aggregated numbers over time\"]\n L --> L1[\"Application events
Detailed records of what happened\"]\n T --> T1[\"Request flow across services
Where time is spent\"]\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n## Prometheus + Grafana\n\nThis combination is the standard for metrics in Kubernetes environments.\n\n**Prometheus** collects and stores time-series metrics. It pulls metrics from your services (they expose an endpoint), stores them efficiently, and provides a powerful query language (PromQL) for analysis and alerting.\n\n**Grafana** visualizes those metrics as dashboards. It connects to Prometheus (and many other data sources) and lets you build dashboards that show system health at a glance.\n\nThis stack is open-source, battle-tested, and runs everywhere. Most Kubernetes clusters come with Prometheus pre-configured.\n\n## Managed Alternatives\n\n**Datadog, New Relic, and Splunk** are commercial platforms that provide metrics, logs, and traces in one package. You pay more, but you get a unified experience and less operational burden.\n\n**CloudWatch** (AWS) is the default for AWS services. It's basic but integrated.\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> Mention monitoring as part of your design. \"We'd expose Prometheus metrics from each service and set up Grafana dashboards for request latency, error rates, and resource utilization. Alerts would fire if p99 latency exceeds 500ms.\" This shows operational maturity.\n\n\n---\n\n# 11. API Gateway\n\nAn API gateway is the front door to your microservices. It's the single entry point that handles cross-cutting concerns so your services don't have to.\n\nInstead of each service implementing authentication, rate limiting, and logging, the gateway handles it centrally:\n\n- **Authentication/Authorization:** Validate tokens before requests reach services\n- **Rate limiting:** Protect services from abuse\n- **Request routing:** Route `/users/*` to the user service, `/orders/*` to the order service\n- **SSL termination:** Handle HTTPS at the edge\n- **Request transformation:** Add headers, rewrite paths\n- **Logging and metrics:** Centralized request logging\n\n## Options\n\n**AWS API Gateway** is fully managed and integrates with Lambda and other AWS services. Good for serverless architectures.\n\n**Kong** is open-source with an enterprise version. Feature-rich, runs anywhere.\n\n**Ambassador/Emissary** is Kubernetes-native, built on Envoy.\n\nFor simpler cases, Nginx or your cloud's load balancer might be enough.\n\n\n> **TIP**\n>\n> #### **Interview tip**\n>\n> In microservices designs, mention an API gateway for handling authentication and rate limiting centrally, rather than implementing these in every service.\n\n\n---\n\n# Technology Selection Framework\n\nChoosing technologies isn't about memorizing which is \"best.\" It's about matching tools to requirements. Here's a mental framework for making those decisions in interviews.\n\n\n```mermaid\nflowchart TD\n A[What are the requirements?]:::primary --> B{Primary Data Store?}\n\n B -->|Structured + Transactions| C[PostgreSQL]:::orange\n B -->|Documents + Flexibility| D[MongoDB]:::orange\n B -->|Massive writes + HA| E[Cassandra]:::orange\n B -->|Key-value + Zero ops| F[DynamoDB]:::orange\n\n A --> G{Need Speed?}\n G -->|Cache hot data| H[Redis]:::green\n G -->|Global static content| I[CDN + S3]:::green\n\n A --> J{Async Communication?}\n J -->|Task distribution| K[RabbitMQ / SQS]:::purple\n J -->|Event streaming| L[Kafka]:::purple\n\n A --> M{Special Needs?}\n M -->|Full-text search| N[Elasticsearch]:::pink\n M -->|File storage| O[S3]:::pink\n M -->|Real-time updates| P[WebSockets]:::pink\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n classDef pink fill:#f783ac,stroke:#000,color:#000\n```\n\n\n## Questions to Ask\n\nBefore naming a technology, ask:\n\n1. **What's the data model?** Relational tables, documents, key-value pairs, time-series?\n2. **What are the access patterns?** Read-heavy, write-heavy, or balanced? Simple lookups or complex queries?\n3. **What scale are we dealing with?** Thousands of users or millions? Gigabytes or petabytes?\n4. **What consistency do we need?** Is eventual consistency acceptable, or do we need strong guarantees?\n5. **What's the latency budget?** Milliseconds for interactive features, seconds for batch jobs?\n6. **What's the operational burden?** Can the team manage this, or should we use a managed service?\n\n---\n\n# Quick Reference\n\nWhen you're in an interview and need to quickly recall which technology to mention:\n\n\n| Problem | Go-to Choice | Alternative |\n|---------|------------|-------------|\n| Relational data, transactions | PostgreSQL | MySQL |\n| Document data, flexible schema | MongoDB | DynamoDB |\n| Massive writes, time-series | Cassandra | TimescaleDB |\n| Caching, leaderboards, sessions | Redis | Memcached |\n| Task queue, work distribution | SQS / RabbitMQ | Redis (simple cases) |\n| Event streaming, logs | Kafka | Pulsar, Kinesis |\n| Full-text search | Elasticsearch | Algolia (managed) |\n| File storage | S3 | GCS, Azure Blob |\n| Load balancing (L7) | ALB / Nginx | HAProxy |\n| CDN | CloudFront / Cloudflare | Akamai |\n| Container orchestration | Kubernetes | ECS, Cloud Run |\n| Metrics + Visualization | Prometheus + Grafana | Datadog |\n\n\n---\n\n# Key Takeaways\n\n**Master the defaults.** Most designs use the same core technologies: PostgreSQL for relational data, Redis for caching, Kafka for event streaming, Elasticsearch for search, S3 for files. Know these well.\n\n**Trade-offs are the point.** There's no universally \"best\" database or queue. Every choice involves trade-offs. The interviewer wants to see that you understand what you're trading away, not just what you're getting.\n\n**Go deep on a few, wide on the rest.** You can't be an expert in everything. Pick 2-3 technologies you know deeply (probably PostgreSQL, Redis, and Kafka or RabbitMQ). For the rest, know enough to choose appropriately and explain why.\n\n**Justify your choices.** \"I'd use Redis\" is weak. \"I'd use Redis because we need sub-millisecond latency for session lookups and it gives us data structures like sorted sets that would be perfect for the leaderboard\" shows understanding.\n\n**Consider operations.** A technology that's theoretically perfect but operationally painful might not be the right choice. Managed services trade cost and lock-in for reduced operational burden. That's often a good trade.\n\n**Stay practical.** Interview answers should reflect what you'd actually do in production. Don't over-engineer. Start with the simplest technology that meets requirements. You can always explain when you'd scale up.\n\n---\n\n# Quiz","pageType":"system-design-interviews"}

Must-Know Technologies for System Design Interviews

Ashish Pratap Singh

Get Premium