67 terms, each with a definition and - more usefully - the specific angle an interviewer will push on. Knowing a definition is table stakes; knowing why it matters is what gets scored.
Push a new item into every follower's precomputed feed, versus assembling the feed at query time.
🎯 Interview angle
Neither works alone: push breaks on celebrities, pull breaks the latency budget. The hybrid - push for normal users, pull for celebrities, merged at read - is the answer.
One entity with vastly more connections or traffic than the rest, breaking an otherwise even design.
🎯 Interview angle
Appears everywhere under different names: hot shard, hot key, hot partition, large chat group. Recognising it as one recurring pattern is a senior signal.
Command Query Responsibility Segregation: separate models for writes and reads.
🎯 Interview angle
Independent of event sourcing, though often paired. Worth it when read and write workloads differ dramatically in shape or volume.
Store the immutable log of events as the source of truth; current state is a projection of it.
🎯 Interview angle
Costs schema versioning forever, replay time, snapshots and GDPR complexity. Most teams wanting 'history' actually want an audit-log table.
Incrementally replace a legacy system by routing capabilities through a facade to new services one at a time.
🎯 Interview angle
The answer to 'how would you migrate?'. Start with a leaf capability owning its own data, never the core domain, and never a big-bang rewrite.
Services split over a network that still must be deployed together and share a database.
🎯 Interview angle
All the cost of microservices and none of the benefit. The diagnostic: can each service be deployed alone, on a Friday, without asking anyone?
A thin per-client-type backend that aggregates and reshapes responses.
🎯 Interview angle
Owned by the client team, contains no business logic. Worth it with four or more diverging clients; overhead with two.
Sidecar proxies handling mTLS, retries, timeouts, load balancing and telemetry between services.
🎯 Interview angle
Below roughly 10–15 services it usually is not worth the overhead. It pays off with multiple languages or mandatory mTLS.
The application checks the cache, reads the database on a miss, and populates the cache itself.
🎯 Interview angle
The default pattern. On write, update the database then **delete** the key - writing the value in lets two concurrent writers leave the older value cached.
A hot key expires and thousands of concurrent requests all miss and hit the origin simultaneously.
🎯 Interview angle
A genuine outage mechanism. Fix with single-flight locking, probabilistic early recompute, or serve-stale-while-revalidate.
Repeated requests for keys that do not exist, so the cache never helps and every request reaches the database.
🎯 Interview angle
A trivially exploitable DoS. Cache negatives briefly and front with a Bloom filter.
Many keys expiring at the same moment because they were populated together with identical TTLs.
🎯 Interview angle
Fixed with one line: add random jitter to every TTL. Frequently the cheapest reliability improvement available.
A Cache-Control directive allowing a stale response to be served immediately while a refresh happens in the background.
🎯 Interview angle
Removes expiry-driven latency spikes and edge stampedes at once. Arguably the highest-value HTTP caching directive.
A balanced tree with all data in the leaves and high fan-out, so a billion rows is only four levels deep.
🎯 Interview angle
Explains why indexed lookups are fast regardless of table size, and why in-place updates make writes random I/O - the contrast with LSM.
Writes buffer in a memtable and flush as immutable sorted files, merged by background compaction.
🎯 Interview angle
Sequential writes make it excellent for high ingest; reads must check several files, so Bloom filters are essential. Compaction causes the p99 spikes that page you at 3 a.m.
A probabilistic set that answers 'definitely not present' or 'possibly present', with no false negatives.
🎯 Interview angle
Used to skip SSTable reads in LSM engines and to stop cache-penetration attacks. ~10 bits per key for a 1% false-positive rate.
A composite index on (a, b, c) can be seeked by a, or a+b, or a+b+c - but never by b alone.
🎯 Interview angle
Explains why one well-ordered composite index beats three single-column ones. Put equality columns before the range column.
An index containing every column a query needs, so the table is never read.
🎯 Interview angle
Turns two reads into one and can be an order of magnitude faster on wide tables. The cost is a larger index and slower writes.
Multi-version concurrency control: keep multiple row versions so readers never block writers and vice versa.
🎯 Interview angle
The cost is vacuum pressure. A long-running idle transaction pins old versions and bloats the database - a real and common outage cause.
Two transactions read an overlapping set, each verifies an invariant, and each writes a different row - jointly breaking the invariant.
🎯 Interview angle
Survives every isolation level below Serializable. The on-call doctors example is the canonical illustration and worth knowing verbatim.
Paginate with `WHERE (sort_key, id) < (last_key, last_id)` rather than OFFSET.
🎯 Interview angle
O(log n) at any depth and stable under concurrent inserts. OFFSET 100000 scans and discards 100,000 rows and drifts between pages.
The column determining which shard a row lives on.
🎯 Interview angle
Must be on most queries, high cardinality, evenly distributed, and colocate rows that need atomic updates. A query without it must scatter-gather across every shard.
One partition receiving a disproportionate share of traffic, usually from a celebrity or whale key.
🎯 Interview angle
Consistent hashing does not fix it - it distributes keys, not traffic. Fixes are compound keys, dedicated shards, or caching the hot key.
During a network partition a system must choose between consistency (linearizability) and availability.
🎯 Interview angle
P is not optional. 'Pick two' is misleading - CAP is a conditional about behaviour during a partition, and most databases are tunable per request.
If Partition then Availability or Consistency; Else Latency or Consistency.
🎯 Interview angle
The 'else' clause describes 99.99% of your operating time and shapes p99 far more than partitions ever will.
Operations appear to take effect instantaneously at a single point between invocation and response - the single-copy illusion.
🎯 Interview angle
This is CAP's C. Distinct from ACID's C, which means constraints hold. Correcting that conflation reliably scores.
Causally related operations are observed in order by everyone; concurrent operations may differ per observer.
🎯 Interview angle
The sweet spot most products actually need. Nobody notices a like count off by one; everybody notices a reply appearing above its message.
With N replicas, requiring W acknowledgements on write and R on read guarantees the sets overlap.
🎯 Interview angle
Necessary but not sufficient for linearizability - you also need read repair and anti-entropy. Saying so is an expert-level detail.
A consensus algorithm using randomised election timeouts, one vote per node per term, and majority commit.
🎯 Interview angle
Two majorities of the same set must overlap, so split brain is impossible. Always use odd cluster sizes - four tolerates no more failures than three.
A monotonically increasing number issued with a lock, checked and enforced by the protected resource.
🎯 Interview angle
The only real fix for TTL-based locks. A GC pause can outlast any lease, so safety must be enforced at the resource, not at the lock.
A data type whose merge is commutative, associative and idempotent, so replicas converge regardless of update order.
🎯 Interview angle
Makes conflicts mathematically impossible rather than resolved. Why collaborative editors work offline. Costs metadata growth and restricted operations.
A sequence of local transactions, each with a compensating action, replacing a distributed transaction.
🎯 Interview angle
You give up isolation: intermediate states are visible. Order irreversible steps last, and remember compensations are not true inverses - a refund is not an un-charge.
Write the event as a row in the same transaction as the state change; a relay publishes it afterwards.
🎯 Interview angle
Eliminates the dual-write problem. Publishing is at-least-once by construction, which is why consumers must be idempotent.
At-least-once delivery combined with idempotent consumers that deduplicate, committing the dedup record with the side effect.
🎯 Interview angle
Exactly-once *delivery* is impossible - the sender cannot distinguish a lost message from a lost ack. Saying that precisely is the whole point.
A client-generated unique key stored with a uniqueness constraint so a retry replays the stored response instead of re-executing.
🎯 Interview angle
Insert first and catch the unique violation - never read-then-write, which races. Commit the key and the effect in one transaction.
The time a single request takes end to end, normally reported as a percentile (p50, p95, p99) rather than an average.
🎯 Interview angle
Always quote a percentile. On a page making 100 backend calls, almost every page load hits at least one p99 - which is why tail latency, not the mean, is what users experience.
Completed requests per unit time, usually requests per second (QPS/RPS).
🎯 Interview angle
Not the inverse of latency. Batching raises throughput while raising per-item latency - being able to say that separates you from candidates who treat them as one dial.
L = λW: concurrency equals arrival rate times time in system. Holds regardless of arrival distribution.
🎯 Interview angle
The fastest way to size thread pools and connection pools. 10,000 QPS at 50 ms means 500 concurrent requests - if your pool is 50, you have found the bottleneck before writing any code.
The fraction of time a system serves requests successfully, expressed in nines. 99.9% ≈ 43 minutes downtime per month.
🎯 Interview angle
Dependencies in series multiply. Six services at 99.9% on the critical path give 99.4% - the hidden cost of microservices.
An SLI is the measurement, an SLO is the internal target, an SLA is the contractual promise with penalties.
🎯 Interview angle
The SLA must always be looser than the SLO. The error budget - the inverse of the SLO - turns arguments about risk into arithmetic.
The allowed failure remaining under an SLO. A 99.9% target permits ~43 minutes of failure a month.
🎯 Interview angle
Frames reliability as a resource to spend. Under budget, ship faster; over budget, freeze features. It converts a values argument into a measurement.
Mean time between failures and mean time to recovery. Availability = MTBF / (MTBF + MTTR).
🎯 Interview angle
MTTR is usually the cheaper lever. A system failing weekly but recovering in 20 seconds beats one failing yearly and taking six hours.
Any component whose failure alone stops the system.
🎯 Interview angle
The non-obvious ones cause real outages: DNS, TLS certificates, config services, the deploy pipeline. Also, three instances in one availability zone is one failure domain, not three.
The difference between a partition's latest offset and the consumer group's committed offset.
🎯 Interview angle
Track per partition and in time units, not messages. A single lagging partition means a hot key or stuck consumer, and it is invisible in an aggregate.
A queue receiving messages that failed repeatedly, so they stop blocking the main flow.
🎯 Interview angle
Always configure one, always alert on non-zero depth, and always build a replay path - otherwise it is a silent data-loss channel.
One IP address announced from many locations; BGP routes each client to the topologically nearest one.
🎯 Interview angle
How CDNs route without DNS tricks, and why they absorb DDoS well - the attack is spread across the whole network rather than concentrated.
One delayed item stalls everything queued behind it. In TCP, a lost packet blocks all bytes after it.
🎯 Interview angle
Why HTTP/2 can be slower than HTTP/1.1 on lossy networks, and the reason QUIC moved reliability above UDP so streams are independently ordered.
A UDP-based transport with per-stream reliability, a merged transport/crypto handshake, and connection migration by connection ID.
🎯 Interview angle
1-RTT setup (0 on resumption), no cross-stream head-of-line blocking, and survives a phone switching from Wi-Fi to cellular. Mention that UDP is blocked on some networks, so fallback is mandatory.
L4 routes on IP and port without reading the payload; L7 parses HTTP and can route by path, host or header.
🎯 Interview angle
The strongest argument for L7 is health checking: a deadlocked process still accepts TCP connections, so only an application-level check knows it cannot serve.
A one-way server-to-client stream over plain HTTP with built-in reconnection and Last-Event-ID resumption.
🎯 Interview angle
The most under-used option in interviews. For notifications, progress and token streaming the client sends nothing, so a WebSocket is unnecessary statefulness.
The number of unique label combinations a metric produces; cost is the product across labels.
🎯 Interview angle
Never put user IDs, request IDs or raw URLs in metric labels. One unbounded dimension can create billions of series and take down the backend.
RED: Rate, Errors, Duration for services. USE: Utilisation, Saturation, Errors for resources.
🎯 Interview angle
The default instrumentation checklist. Quoting it shows you know what to measure before being asked.
Deciding whether to keep a trace after it completes, so you can retain all errors and slow requests.
🎯 Interview angle
Head sampling at 1% discards nearly every error trace, because errors are rare. Tail sampling keeps exactly the traces worth investigating.
Rejecting requests immediately under overload rather than queueing them.
🎯 Interview angle
Rejecting in 1 ms beats timing out in 30 s: a fast rejection frees resources on both sides, while a slow timeout holds them on the client and the server.
After N consecutive failures, stop calling a dependency for a cooldown, then probe with a half-open state.
🎯 Interview angle
Gives a struggling dependency room to recover instead of holding it underwater with continued traffic.
Capping retries as a fraction of total traffic rather than as a fixed count per request.
🎯 Interview angle
During a wide outage the budget empties and retries stop - the opposite of a fixed count of 3, which multiplies load exactly when the system is worst.
Retries multiplying across layers: three layers each retrying twice turns one request into 27.
🎯 Interview angle
The mechanism behind most cascading failures. Retry at one layer only, with backoff and full jitter.
Bounded, separate resource pools per dependency so one slow dependency cannot starve the others.
🎯 Interview angle
A shared thread pool means one dependency slowing to 5 s parks every thread and takes down unrelated endpoints.
How much of the system a single failure affects.
🎯 Interview angle
Cell-based architecture bounds it: partition users into independent vertical stacks so a bad deploy damages 5% rather than everyone.
Recovery Time Objective is how long until service returns; Recovery Point Objective is how much data may be lost.
🎯 Interview angle
Business decisions before engineering ones. And an untested backup is not a backup - quote the measured restore time.
Map keys and nodes onto a ring; a key belongs to the first node clockwise. Adding a node moves only ~1/N of keys.
🎯 Interview angle
`hash(key) % N` remaps ~91% of keys when going from 10 to 11 nodes. Virtual nodes are required, not optional, for even distribution.
Placing each physical node at many ring positions (typically 100–200) so arcs are even.
🎯 Interview angle
Without them, three nodes on three random positions can split 60/20/20. They also spread a removed node's keys across all survivors.
Sample two backends at random and send to the less loaded one.
🎯 Interview angle
Reduces maximum load from O(log n / log log n) to O(log log n) with no coordination - near-optimal balancing, which is why service meshes use it.
Signalling upstream to slow down when a consumer cannot keep pace.
🎯 Interview angle
When λ > μ no configuration saves you. Options are scale consumers, shed load, throttle producers or bound the queue. Alert on message age, not depth.
A data key encrypts the data; a KMS master key encrypts the data key, which is stored beside the ciphertext.
🎯 Interview angle
Rotating the master key re-encrypts small data keys, not terabytes of data - and bulk encryption never calls the KMS, so throughput is unbounded by it.
The network grants no authority; every call is authenticated and authorised regardless of origin.
🎯 Interview angle
Replaces the hard-perimeter model. In practice: mTLS between services, short-lived workload identities, least-privilege scopes everywhere.
Issuing a new refresh token on each use and invalidating the old one; reuse of a spent token signals theft.
🎯 Interview angle
The standard mitigation for the JWT revocation problem. Reuse detection lets you revoke an entire token family immediately.