Loading…
Loading…
A skill is an axis you’re graded on; a pattern is a system shape; a technology is the concrete tool you actually reach for. Interviewers expect you to name a specific one and go deep — “a Redis sorted set for the leaderboard”, not “a cache”. Each deep dive covers what it is, how it works under the hood, its real performance envelope, the capabilities that come up in interviews, and the failure modes that catch people out.
The systems of record — relational, wide-column, and key-value.
A relational database with ACID transactions, rich SQL, indexes and replicas; use it first when correctness and flexible queries matter.
Reach for it when: The default for product-design interviews — user records, orders, relationships, anything transactional
A managed key-value and document store for known access patterns, where key design gives low latency without operating shards.
Reach for it when: Access patterns are known up front and are key-based (get/put by id, query by partition key)
A masterless wide-column store for write-heavy, multi-region systems with predictable partition-key queries.
Reach for it when: Write-heavy workloads at scale — time-series, event logs, sensor/IoT data, messaging history, feeds
The speed and discovery layers that sit in front of and beside your stores.
An in-memory store of data structures, used in designs for caching, locks, leaderboards, rate limits, nearby search, queues and pub/sub.
Reach for it when: You need a cache in front of a slower store and want sub-millisecond reads
A distributed search engine for full-text relevance, filters, facets and log analytics when a database scan or simple index is not enough.
Reach for it when: Full-text search is a real feature — relevance ranking, typo tolerance, autocomplete
A search store for embedding vectors, used when you need similarity by meaning for semantic search, recommendations or RAG.
Reach for it when: Semantic search — match by meaning, not keywords (Q&A, "find similar", dedup)
A retained, partitioned event log for durable streams, replay, and many independent consumer groups.
Reach for it when: You need a durable, replayable event stream that many independent consumers read
A stream-processing engine for stateful real-time computation: windows, joins, enrichment and live materialised views.
Reach for it when: Real-time windowed aggregations — counts, sums, percentiles per interval (ad clicks, metrics)
The infrastructure that moves bytes, routes traffic, and keeps a cluster honest.
Durable object storage for large unstructured bytes, with databases holding metadata and CDNs handling delivery.
Reach for it when: You store large files — images, video, audio, PDFs, user uploads, ML data
A thin front door for client traffic: it authenticates callers, applies quotas, validates and routes requests, and keeps those cross-cutting concerns out of each service.
Reach for it when: You have multiple backend services and want one client-facing entry point
A traffic director for a server fleet: clients use one endpoint while the load balancer spreads requests, checks health and drains failed backends.
Reach for it when: You run more than one server and need to spread traffic across them
A global edge cache for HTTP content: serve repeat reads near users, keep cacheable traffic away from origin, and use TTLs and keys to bound staleness.
Reach for it when: You serve static assets or media (images, video, bundles) to a global audience
A consensus-backed coordination store for leader election, locks, config and service discovery when only one actor is allowed to win.
Reach for it when: You need leader election or a single active coordinator across a cluster
A task buffer between producers and workers, used for async jobs, retries, dead-letter handling and burst smoothing.
Reach for it when: Background / asynchronous jobs — email, transcoding, image processing, report generation