Key technologies

Interviews reward a small, well-justified toolbox over a large, name-dropped one. Nobody cares if you pick Kafka or SQS — only that you have a queue you can reason about under pressure. The real failure mode is not knowing any queueing solution at all: async workloads become impossible to design, not just suboptimal.

The categories below cover roughly 90% of interview problems. Pick within each category however you like — but show up with at least one name you actually know well.

Already know the concepts? Start with Core concepts overview for the theory layer beneath these tools.

Almost every design stores data in a database or blob storage. The two real choices are relational (Postgres) and NoSQL (DynamoDB) — pick by the shape of the interview more than the specific problem.

Good opener: "I'm using Postgres here because ACID transactions keep order and inventory consistent." If you're pushed to compare, compare databases you actually know — and say how each one would change the design, not which one wins in the abstract.

Reach for Postgres or MySQL when the data is transactional and the relationships matter: users, orders, bookings. Rows and columns, queried with SQL.

Don't reach for Postgres when your access pattern is one huge table, always queried by a single key, at extreme write volume — that's a NoSQL problem, not a tuning problem. Otherwise: pick Postgres or MySQL. No preference? Postgres — every interviewer has an opinion about it, which works in your favor.

NoSQL covers key-value, document, column-family, and graph stores — schema-flexible, built for horizontal write scale.

Common picks: DynamoDB (breadth, interview familiarity), Cassandra (write-heavy, append-only, fewer query guarantees in trade), MongoDB (document store). Failure mode: the moment your access pattern needs an ad-hoc query you didn't design a GSI for, latency and cost both spike. Constantly inventing new query shapes is the signal you actually wanted Postgres.

Images, videos, PDFs don't belong in Postgres or DynamoDB rows. Push them to S3, GCS, or Azure Blob — cheap, durable, and effectively infinite for interview purposes.

Pattern: DB stores pointers (URLs); blob store holds bytes. Query and index in the DB; serve bytes from S3 + CDN.

Upload flow (presigned URLs):

Download: server returns a presigned URL, client fetches via CDN, CDN proxies to S3 origin on a miss.

WHERE text LIKE '%term%' scans every row — dies at scale. Search engines use inverted indexes instead: word → list of documents.

Look up the query token, get an instant candidate document list. Fast because you never touch the rows that don't match.

Leader: Elasticsearch (Lucene underneath). Don't stand up a whole Elasticsearch cluster for a search box hitting under ~10k rows — Postgres GIN full-text covers that without a second system to operate and page on. Reach for Redis search only for small, latency-critical lookups; it's not mature enough yet for heavy search workloads.

In microservices — and most product designs — an API gateway is the front door: route GET /users/123 to the users service, handle auth, rate limits, logging, all before any business logic runs.

Interviewers rarely deep-dive gateway internals: draw the box, name the cross-cutting concerns, move on. Don't bother drawing one for a single-service toy design — a gateway earns its place once you actually have more than one service behind it.

Common options: AWS API Gateway, Kong, Apigee, or plain nginx/Apache, the way early Amazon did it.

High traffic means spreading requests across machines. For most interviews, the load balancer is a black box that distributes work — you rarely need to go deeper than that.

Common: AWS ELB, NGINX, HAProxy. Extreme traffic pushes you into hardware LB territory — rare in interviews, but a clean escape hatch if someone insists the LB itself is the bottleneck.

Queues buffer bursty traffic and decouple producers from consumers. The producer sends a message and moves on; workers process at their own pace.

Common: Kafka (streaming + queue), SQS (managed, simple). → Full message queues article

Streams retain data for a configurable window — consumers can re-read from any point in time. Unlike a one-shot queue, a stream is a durable log.

Common: Kafka, Flink, Kinesis.

Need to hold a resource while one user completes checkout? DB row locks work for a transaction that finishes in milliseconds — not for a 10-minute cart hold sitting open while someone finds their wallet. Use a distributed lock instead (Redis, ZooKeeper).

Scale reads and cut latency by keeping hot data in memory. Redis or Memcached clusters sit beside your database, not instead of it.

Pick: Redis (rich structures) or Memcached (simple strings). Don't cache first and measure never — a cache with no invalidation story just serves stale data confidently. → Caching strategies

A CDN caches content on edge servers near users. A request routes to the closest point of presence — a hit returns instantly, a miss fetches from origin, caches it, and returns.

Common: Cloudflare, Akamai, CloudFront. Don't cache anything personalized or write-heavy at the edge — a CDN serving a stale per-user cart page is a bug that files itself.