Understanding system design concepts is essential. But you also need to know the technologies that implement those concepts.

When 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.

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 what each tool is good at, where it becomes painful, and what requirement would make you choose it.

This 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.

Before diving into specifics, here's the mental map. Every system design essentially combines technologies from these categories:

Think 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.

Let's explore each category.

Relational databases are the starting point for many applications. When your data has clear structure, relationships matter, and transactions protect correctness, this is usually where you begin.

PostgreSQL is a reasonable starting point for many interview designs because it gives you relational modeling, mature transactions, good indexing, and enough flexibility to handle some semi-structured data.

What makes PostgreSQL stand out:

PostgreSQL covers the core relational requirements well. Full ACID compliance gives reliable transaction behavior, and MVCC (Multi-Version Concurrency Control) lets readers and writers proceed without blocking each other in common cases.

Its advanced features are often what make it easier to keep using as the system grows:

Use PostgreSQL when:

Think twice when:

MySQL is widely deployed and well understood by many teams. Compared with PostgreSQL, it is often chosen for operational familiarity, straightforward relational workloads, and mature managed-service support.

Why MySQL still matters:

MySQL's strength is its simplicity and long operational history. The InnoDB storage engine provides solid ACID transactions. Read replicas are straightforward to set up. The ecosystem is broad: every major language has mature MySQL drivers, and every cloud offers managed MySQL.

For read-heavy web applications with straightforward data patterns, MySQL is a practical choice. Its strength is not breadth of features; it is predictability, ecosystem maturity, and a large pool of operational experience.

MySQL vs PostgreSQL:

Which to choose?

For a new project, PostgreSQL is often easier to justify because its feature set is broader. MySQL is still a good answer when the workload is simple, the team operates it well, or existing infrastructure already depends on it.

In 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.

NoSQL 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.

The useful skill is knowing which model fits the access pattern.

MongoDB is one of the best-known NoSQL databases. It stores data as JSON-like documents, making it natural for applications that already think in JSON.

Why MongoDB works:

The 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.

MongoDB 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.

MongoDB fits when

MongoDB struggles when

Cassandra is built for write-heavy, highly available workloads spread across many nodes or regions. It is a good fit when availability and horizontal write scaling matter more than flexible querying.

Why Cassandra exists:

Cassandra was born at Facebook to solve their inbox search problem, then open-sourced and adopted by large-scale internet companies. Its design assumes nodes will fail and the system should continue serving traffic.

Every 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).

Need stronger consistency? Use quorum reads and writes so the read and write quorums overlap. Need maximum availability and lower latency? Accept fewer acknowledgments, but expect stale reads during failures or replication lag.

Cassandra is the right choice when:

Cassandra is the wrong choice when:

DynamoDB 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.

The DynamoDB proposition:

DynamoDB 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.

Those 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.

Want to query by an arbitrary field? You need a secondary index. Want complex aggregations? You're better off with something else.

DynamoDB makes sense when:

DynamoDB doesn't make sense when:

Here's a decision framework:

Caching 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.

Redis is often the first cache to consider because it is fast, familiar, and supports useful in-memory data structures. It can also handle session storage, rate limiting, leaderboards, lightweight pub/sub, and counters when those needs fit in memory.

Why Redis is useful:

Redis is useful because it gives you more than string keys and values:

Each data structure solves specific problems elegantly:

Redis 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.

Redis is commonly used for

Memcached 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 with low latency.

When would you pick Memcached over Redis?

Redis is usually easier to justify because it covers more use cases, but Memcached still has a place when you only need a simple cache:

Redis vs Memcached at a glance:

Practical recommendation: Start with Redis unless the requirement is only key-value caching and you have a specific performance or memory-efficiency reason to prefer Memcached.

This 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.

Kafka isn't a traditional 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.

Why this matters:

This log-based model changes what the system can support:

Kafka's architecture

Topics 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.

Kafka is the right choice when

Kafka is usually too much when

RabbitMQ 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.

RabbitMQ fits when:

RabbitMQ 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.

It 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.

RabbitMQ vs Kafka:

A useful rule: If you need work distribution (one message = one task for one worker), consider RabbitMQ. If you need event streaming (one event potentially processed by many systems), consider Kafka.

SQS is AWS's managed queue service. It is a practical choice when you are already on AWS and need a reliable queue without operating brokers.

Why SQS makes sense:

You do not manage servers or broker clusters. You create a queue, send messages, receive messages, and AWS handles availability, durability, and scaling.

SQS offers two queue types:

SQS is the right choice when:

SQS is limiting when:

Choosing between message technologies:

When 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.

Elasticsearch is a common choice for full-text search and log analytics. Built on Apache Lucene, it provides relevance scoring, inverted indexes, aggregations, and a query language exposed over HTTP.

Why you need Elasticsearch:

Your PostgreSQL database can do basic search with LIKE queries, but it struggles with:

Elasticsearch handles all of this natively.

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.

Common Elasticsearch use cases

Elasticsearch considerations

Elasticsearch is not usually your system of record. It is optimized for search and analytics, not transactional integrity, relational constraints, or serving as the authoritative source for critical writes. Use it alongside a primary data store.

It also has a learning curve. The query DSL is expressive but complex. Indexing strategies, mapping types, and shard configuration require thought.

Your database stores structured data. But what about profile pictures, uploaded documents, video files, and backups? That's where object storage comes in.

S3 is the common AWS answer for object storage: uploaded files, media, backups, static assets, and data-lake objects.

Why S3 is commonly used:

S3 offers effectively unlimited object storage and very high durability. In interviews, the exact durability math matters less than the role: object storage is built for durable, cheap, large-scale blob storage rather than low-latency relational queries.

S3 storage classes save money

Not all data is accessed equally. S3 offers storage classes that trade access speed for cost:

Lifecycle policies automate transitions. For example: after 30 days, move to IA. After 90 days, move to Glacier. After 7 years, delete.

Common S3 patterns

HDFS is specialized for big data. If you're processing terabytes or petabytes with Hadoop, Spark, or similar frameworks, HDFS is purpose-built for that.

Unlike S3-style object storage, HDFS behaves like a distributed filesystem for batch processing workloads. It fits best when your processing framework expects locality-aware file access.

When to mention HDFS in interviews: legacy Hadoop environments, batch processing, and data platforms that already depend on HDFS. For general cloud file storage, object storage is usually simpler.

When 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."

The key distinction is what layer of the network stack the load balancer understands:

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.

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.

Nginx is a common choice when you need an HTTP server, reverse proxy, or software load balancer that you can run and configure yourself.

Nginx is useful when you need:

For simpler self-managed setups, Nginx is often enough. In cloud-native environments, a managed load balancer or ingress controller may be simpler operationally.

If you're on AWS, GCP, or Azure, managed load balancers reduce operational work:

A 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.

Why CDN Matters

The 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.

A CDN puts cached copies of your content on edge servers worldwide. Now that Tokyo user hits a Tokyo edge server with ~10ms latency.

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.

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.

Containers 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.

Docker packages your application and its dependencies into a container, which runs consistently across environments. No more "it works on my machine" problems.

You don't need deep Docker knowledge for system design interviews, but understand the basics:

Kubernetes (K8s) manages containerized applications across a cluster of machines. It handles the operational concerns that become critical at scale.

What Kubernetes gives you

Key concepts to know

You can't fix what you can't see. In production, observability is how you understand what your system is doing: is it healthy, is it fast enough, and when something breaks, why?

The Three Pillars

Modern observability combines three types of data:

This combination is the standard for metrics in Kubernetes environments.

Prometheus collects and stores time-series metrics. It pulls metrics from your services (they expose an endpoint), stores them efficiently, and provides PromQL for analysis and alerting.

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.

This stack is open-source, widely used, and fits Kubernetes environments well. Many Kubernetes setups already include Prometheus-compatible metrics.

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.

CloudWatch (AWS) is the built-in monitoring option for AWS services. It is integrated, but teams often add specialized observability tools as systems grow.

An 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.

Instead of each service implementing authentication, rate limiting, and logging, the gateway handles it centrally:

AWS API Gateway is fully managed and integrates with Lambda and other AWS services. Good for serverless architectures.

Kong is open-source with an enterprise version. Feature-rich, runs anywhere.

Ambassador/Emissary is Kubernetes-native, built on Envoy.

For simpler cases, Nginx or your cloud's load balancer might be enough.

Choosing 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.

Before naming a technology, ask:

When you're in an interview and need to quickly recall which technology to mention:

Know the common starting points

Many designs start with PostgreSQL for relational data, Redis for caching, Kafka for event streaming, Elasticsearch for search, and S3 for files. Treat these as defaults to justify, not names to memorize.

Tradeoffs are the point

There's no universally "best" database or queue. Every choice involves tradeoffs. A strong answer shows that you understand what you're trading away, not just what you're getting.

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.

Justify your choices

"I'd use Redis" is weak. "I'd use Redis because we need sub-millisecond latency for session lookups, and sorted sets fit the leaderboard access pattern" shows understanding.

Consider operations

A technology can fit the model and still be operationally expensive. Managed services trade cost and lock-in for reduced operational burden. That's often a good trade.

Stay practical

Interview answers should reflect what you'd do in production. Don't over-engineer. Start with the simplest technology that meets requirements. You can explain when you'd scale up if requirements change.