Key technologies: an overview

Every design is assembled from the same small set of off-the-shelf parts. You do not need to know every product. You need to know what each kind of part is for, when to use it, and what it costs you.

Crux: know at least one tool in every category, why you would choose it, and its main trade-off. The category matters more than the brand.

How to talk about technologies

A few habits make the difference between a design that sounds confident and one that sounds like a list of names.

• Know the categories, then one option in each. The person listening mostly needs to hear that you have an answer for each need. If you know no queueing tool, any design with a queue is hard to defend.
• Breadth first, depth second. Cover every category before going deep in one. The depth expected grows with seniority.
• Pick one core database and know it well. A relational database is the usual choice for product designs. A NoSQL database is the usual choice for infrastructure designs.
• Do not argue "SQL vs NoSQL" in general. It is a trap. Talk about the features of the database you picked, for example the transactions and guarantees of Postgres.
• Be specific. Not "I'll store it in a cache," but "I'll keep a sorted set in Redis, because I need ranked results."

The map

Most systems look like this. A request passes through the edge, reaches the app servers, and the app servers lean on a handful of supporting parts.

The categories

Relational databases

• What: tables of rows and columns, queried with SQL. Postgres and MySQL are the usual examples.
• Use when: you have transactional data with relationships. This is the default for product design.
• Know: joins (powerful, but can become a bottleneck), indexes (B-tree and hash) and transactions.

NoSQL databases

• What: key-value, document, wide-column and graph stores, often with a flexible schema. DynamoDB, Cassandra and MongoDB are common.
• Use when: the schema keeps changing, you need to scale out horizontally, or you handle very large or real-time data.
• Know: the consistency models (strong to eventual), how indexing works, and how it spreads data (consistent hashing, sharding). Cassandra suits write-heavy loads, since it appends to storage.
• Careful: "I need NoSQL for scale" is not a reason. Say what feature you need.

Blob storage

• What: cheap storage for large files such as images and video. S3, Google Cloud Storage and Azure Blob are the usual names.
• Use when: you store large unstructured files. Keep the file in blob storage and a URL pointer in your database. Do not use it as your main database.
• Know: presigned URLs let clients upload and download directly, a CDN usually sits in front for downloads, and multipart upload splits big files into chunks.

Search databases

• What: full-text search built on an inverted index (word to documents), with tokenising, stemming and fuzzy matching. Elasticsearch is the clear leader.
• Use when: you search text across a large dataset. A LIKE '%term%' query forces a full table scan.
• Know: your existing database may already offer basic search (for example Postgres full-text indexes). Using it keeps the design smaller, but know the dedicated option exists.

API gateway

• What: the single entry point that routes requests to services and handles authentication, rate limiting and logging.
• Use when: almost always in a product design, as the first box after the client.
• Know: it is rarely probed in depth. Draw it, say what it handles, and move on.

Load balancer

• What: spreads traffic across many machines that serve the same requests.
• Use when: more than one machine serves the same job. Draw one at the front, not one before every service.
• Know: use layer 4 for persistent connections such as WebSockets. Otherwise layer 7 gives more routing control.

Queues

• What: a buffer between a producer and a consumer, so each can scale on its own and bursts are smoothed out. Kafka and SQS are common.
• Use when: traffic is bursty, or you hand work to a pool of workers.
• Do not use when a user is waiting on a strict latency target. A queue in that path will almost certainly break it.
• Know: ordering, retries, dead-letter queues, partitioning by key and backpressure.

Streams and event sourcing

• What: a log of events that is kept and can be replayed, unlike a queue. Kafka, Flink and Kinesis are common.
• Use when: high-volume real-time processing, event sourcing (such as every bank transaction), or several independent consumers reading the same events.
• Know: partitioning, consumer groups, replication and windowing, for example "average delivery time per region over the last 24 hours".

Distributed locks

• What: a lock shared by many processes, usually built on Redis or ZooKeeper.
• Use when: you must hold a resource briefly, such as a ticket for about ten minutes, a driver assignment, or the last moments of an auction.
• Know: always set an expiry so a crashed holder does not block everyone, keep locks fine-grained, and avoid taking locks from many places in the code.
• Careful: a database transaction lock is not meant for long holds. And a lock needs an atomic "set if absent, with expiry" step, not a plain check-then-set.

Distributed cache

• What: fast in-memory storage spread across servers. Redis and Memcached are the usual choices.
• Use when: you can save repeated work: aggregated metrics, sessions, hot reads, expensive queries.
• Know: eviction policies (LRU, FIFO, LFU), invalidation, and the write strategies (write-through, write-around, write-back). Write-back is fastest, and it can lose data.

CDN

• What: servers at the edge that serve content from the location nearest to the user. Cloudflare, Akamai and CloudFront are common.
• Use when: static media, and sometimes dynamic content or API responses that rarely change.
• Know: time-to-live (TTL) settings and how to invalidate.

Defaults to start from

When you need to name something, start from a familiar default. It does not have to be the final answer.

If you do not know blob storage well, choose S3. If you do not know a queue, choose Kafka. Familiar beats clever.

Common mistakes

• Listing products without saying what each one is for.
• Choosing a technology because it is popular, not because of a property you need.
• Putting a queue where a user is waiting for an instant answer.
• Using blob storage as the main database.
• Drawing a load balancer in front of every service.
• Saying "I'll use a cache" without saying what is cached and how it is kept fresh.

Check yourself

• Name one tool in each category, and one reason to pick it.
• Why is a general "SQL vs NoSQL" argument weak, and what should you say instead?
• When is a queue the wrong tool?
• Where do large files live, and what goes in the database instead?
• Why must a distributed lock have an expiry?
• When do you use a layer 4 load balancer?