system-design

Tools of the Trade

A quick-reference map of the real technologies behind the abstract building blocks in this repo. When a case study says “use a cache” or “use a message queue,” these are the actual tools people reach for. Knowing the names — and roughly when to pick each — makes your designs concrete and your interviews credible.

Time to read: ~10 minutes; a reference to return to

Why know the tools

🚨 You design with abstractions (“a cache,” “a queue”), but naming real tools shows you know the landscape — “I’d use Redis for the cache and Kafka for the event log” is more credible than staying purely abstract. Caveat: don’t name-drop tools you can’t discuss. Know roughly what each is and when you’d choose it; depth beats breadth. This is a map, not a memorization task.

The landscape, by building block

Databases (relational / SQL)

PostgreSQL — the versatile default; powerful, reliable, feature-rich. 🚨 A great “boring, correct” choice.
MySQL / MariaDB — ubiquitous, well-understood.
CockroachDB, Google Spanner, YugabyteDB — distributed SQL (horizontal scale + strong consistency).
Amazon Aurora — cloud-native managed MySQL/Postgres. → Use for transactions, relational data, strong consistency. Choosing a Database

NoSQL

Cassandra, ScyllaDB — wide-column, write-heavy, highly available (Dynamo lineage). Time-series, feeds, logs.
Amazon DynamoDB — managed key-value/document; predictable performance, serverless.
MongoDB — document store; flexible schema.
HBase — wide-column on Hadoop. → Use for scale, flexible schema, simple access patterns. NoSQL Modeling

Caching

🚨 Redis — the de facto in-memory store; also does sorted sets (leaderboards), pub/sub, rate limiting, geo. Enormously versatile.
Memcached — simpler, pure cache. → Caching · Distributed Cache

Message queues / streaming

🚨 Apache Kafka — the dominant distributed log; streaming, event sourcing, high throughput.
RabbitMQ — traditional message broker (task queues, routing).
Amazon SQS / SNS, Google Pub/Sub — managed queue/pub-sub.
Apache Pulsar, Redpanda — Kafka alternatives. → Message Queues · Kafka

Search

🚨 Elasticsearch / OpenSearch — the standard full-text search + inverted index; also log search.
Apache Solr — the older Lucene-based option.
Algolia — managed search-as-a-service; great for typeahead. → Search Systems · Search case study

Object storage & CDN

Amazon S3, Google Cloud Storage, Azure Blob — the blob stores behind every large-payload design.
CDNs: Cloudflare, Amazon CloudFront, Akamai, Fastly. → Object Storage · CDN

Stream / batch processing

Apache Flink — the leading stream processor (event-time, windows). Ad aggregator.
Apache Spark — batch + streaming, big data processing.
Kafka Streams, ksqlDB — stream processing on Kafka. → Batch vs Stream

Time-series & metrics

Prometheus (metrics + alerting), InfluxDB, TimescaleDB (time-series DBs), Grafana (dashboards). Metrics case study.

Coordination / config

ZooKeeper, etcd, Consul — distributed coordination, leader election, service discovery, config. Coordination Services.

Load balancing / gateway / proxy

NGINX, HAProxy, Envoy — load balancers / proxies.
Kong, AWS API Gateway — API gateways.
Istio, Linkerd — service meshes. → Load Balancers · API Gateway · Service Mesh

Containers, orchestration, infra

Docker (containers), Kubernetes (orchestration), Terraform (IaC), Helm.
Clouds: AWS, GCP, Azure (and regional: many MENA/SEA companies use these). → Deployment & Infra

Observability

Prometheus + Grafana (metrics), ELK / OpenSearch (logs), Jaeger / OpenTelemetry (tracing), Datadog (all-in-one SaaS). → Observability

A cheat-map: “when a case study says X, reach for…”

Abstraction	Common real tools
Cache	Redis, Memcached
Relational DB	PostgreSQL, MySQL, Aurora
Scalable NoSQL	Cassandra, DynamoDB, MongoDB
Message queue / log	Kafka, RabbitMQ, SQS, Pub/Sub
Full-text search	Elasticsearch, Algolia
Object storage	S3, GCS
CDN	Cloudflare, CloudFront
Stream processing	Flink, Spark, Kafka Streams
Coordination	ZooKeeper, etcd
Metrics / dashboards	Prometheus, Grafana
Orchestration	Kubernetes, Docker

🚨 A caution on tools

Depth over name-dropping. Naming Kafka then not knowing what a partition is hurts you. Know each tool well enough to justify picking it.
The abstraction matters more than the brand. Understanding why you need a log matters more than whether it’s Kafka or Pulsar. Interviewers care about the reasoning.
Boring is good. In real systems (and startup interviews especially), proven, managed, “boring” tools (Postgres, Redis, S3) are usually the right, mature choice over the trendy new thing.
Tools change; concepts don’t. This list will age; the building-block concepts won’t. Learn the concepts; treat tools as their current implementations.

🛠️ Try it

1. Fill the cheat-map from memory. Cover the right column and name two real tools for each abstraction. The gaps are what to read up on.

2. Justify one tool per building block. For Redis, Kafka, Postgres, S3, and Elasticsearch, write one sentence on when you’d choose it and why. That justification is what interviews want.

3. Get hands-on with one. Spin up Redis or Postgres locally (or Kafka via Docker) and use it in a build-it project. Using a tool once beats reading about it ten times.