213 concepts, A to Z.
Every idea the course teaches, in one line, with a two-minute refresher and the lesson that teaches it properly.
A
- ACIDW00 · Part 6Atomicity, consistency, isolation, durability: a database transaction is all-or-nothing, valid, isolated from others and permanent once committed.
- Active-passiveW00 · Part 6A redundancy pattern: the primary serves all traffic while a standby replicates its data and is promoted if the primary fails.
- Adaptive timeoutW02 · Day 1A timeout recomputed from recent observed latency (such as recent P99 × a safety factor) instead of a fixed number.
- Allowed latenessW08 · Day 4How long a window keeps its state after firing so late events can still update it; anything later is dropped or side-output.
- At-least-once deliveryW00 · Part 6Messages are retried until acknowledged, so none are lost, but some may arrive more than once.
- At-most-once deliveryW00 · Part 6Each message is delivered zero or one times: never duplicated, but it may be lost.
- Audit logW03 · Day 5An immutable, chronological record of who did what to which resource, when and from where, kept for security and compliance.
B
- B-tree indexW00 · Part 6The default database index: a balanced tree giving O(log n) lookups, range scans and sorted reads instead of full table scans.
- Back-of-the-envelope estimationW00 · Part 3Quick, rounded arithmetic on traffic, storage, bandwidth and servers, so design decisions rest on numbers instead of guesses.
- BackpressureW03 · Day 3What happens when a downstream can't keep up with an upstream, and the signals or mechanisms that slow the producer to match.
- BASEW00 · Part 6Basically available, soft state, eventually consistent: the availability-first alternative to ACID used by many distributed stores.
- Blameless postmortemW10 · Day 5A written review after an incident that asks why the system allowed the failure, not who erred, and ends in concrete action items.
- Blue-green deploymentW10 · Day 3Running two identical environments, deploying the new version to the idle one and switching all traffic at once, with instant rollback.
- BM25W07 · Day 3The standard relevance score: rewards terms frequent in a document (with diminishing returns) and rare across the corpus, normalising for length.
- BoostingW07 · Day 3Raising the weight of some matches, such as a title match over a description match, or fresher and more popular items.
- BulkheadW02 · Day 3Isolating resources per dependency (separate thread pools or semaphores) so one slow dependency can't consume everything.
- Burn rateW10 · Day 1How fast the error budget is being spent relative to the even pace; 14.4× for an hour burns 2% of a 30-day budget.
C
- Cache hit ratioW04 · Day 1The share of requests served from the cache: hits ÷ (hits + misses). Higher means less load on the source.
- Cache invalidationW04 · Day 2Removing or updating cached entries when the source data changes, so readers don't keep seeing stale values.
- Cache warmingW04 · Day 3Pre-loading the cache with likely-hot data before traffic arrives, so a deploy, restart or launch doesn't start cold.
- Cache-asideW04 · Day 1The application checks the cache first; on a miss it reads the database and writes the result into the cache.
- Cache-ControlW04 · Day 5The HTTP header telling browsers and CDNs whether and how long to cache a response: max-age, private, public, no-store, no-cache.
- Canary deploymentW10 · Day 3Sending a small share of traffic (1%, then 10%, 50%, 100%) to the new version and comparing its metrics with stable before going further.
- CAP theoremW00 · Part 6During a network partition a distributed system must choose consistency (refuse or error) or availability (answer, maybe stale).
- Capacity planningW10 · Day 4Measuring current limits, forecasting demand and adding capacity ahead of it, keeping headroom: the spare share of maximum capacity.
- Cascading failureW02 · Day 1One slow or failing service exhausts its callers' threads or connections, so failure spreads up the call chain.
- Causal consistencyW00 · Part 6Operations that are causally related (a reply after the post it answers) are seen in that order by everyone; concurrent ones may differ.
- CDNW00 · Part 2A geographically distributed network of edge servers that caches content close to users, cutting latency and offloading the origin.
- Change data captureW07 · Day 2Streaming every insert, update and delete from a database's transaction log (WAL or binlog) to other systems as events.
- ChoreographyW05 · Day 2Saga coordination without a central coordinator: each service reacts to events and publishes its own.
- Circuit breakerW02 · Day 3A wrapper around calls to a dependency that stops calling it after repeated failures, fails fast, then cautiously probes for recovery.
- Columnar storageW08 · Day 3Storing each column's values together on disk, so analytical queries read only the columns they need and compress far better.
- Compensating transactionW05 · Day 2A new transaction that semantically undoes an earlier saga step, such as refunding a charge, since a committed step can't be rolled back.
- Connection poolingW00 · Part 4Keeping a set of open connections and reusing them across requests, instead of paying a new handshake each time.
- Connection timeoutW02 · Day 1Connect timeout limits establishing the TCP connection; read timeout limits waiting for response data. Both need explicit values.
- ConsensusW05 · Day 5Getting a group of nodes to agree on one value or one ordered log, despite failures, as long as a majority is up (Raft, Paxos).
- Consistent hashingW01 · Day 1Keys and nodes are hashed onto a ring; each key belongs to the next node clockwise, so adding a node moves only one arc.
- Consumer groupW03 · Day 1A set of consumers sharing a topic: each group gets every message, and within a group each partition goes to one consumer.
- Consumer lagW03 · Day 3How far a consumer is behind the newest messages, in messages or time; steadily growing lag means it can't keep up.
- Consumer offsetW03 · Day 1A consumer's position in a stream partition: how far it has read; committing it records progress for restarts.
- Consumer rebalanceW03 · Day 1Reassigning a topic's partitions among a group's consumers when one joins, leaves or crashes, pausing consumption briefly.
- Context switchW00 · Part 5The OS saving one thread or process's CPU state and loading another's; frequent switches waste CPU time and caches.
- Coordination serviceW05 · Day 5A small, strongly consistent store (ZooKeeper, etcd) built on consensus, used for leader election, locks, configuration and membership.
- Count-min sketchW01 · Day 4A fixed-memory probabilistic counter that estimates per-key frequencies (never under-counting), used to spot hot keys in real time.
- CQRSW00 · Part 6Command Query Responsibility Segregation: writes go to one model, reads come from separate models projected and optimised for queries.
- CRDTW05 · Day 4A data structure replicas update independently and merge automatically, with merges that are commutative, associative and idempotent.
D
- Data residencyW09 · Day 3Where data is physically stored and processed; residency rules require some data to stay within a country or region.
- Dead letter queueW03 · Day 4A queue where messages go after exceeding their retry limit, to be inspected, fixed and replayed instead of blocking the main queue.
- Deduplication windowW02 · Day 2How long processed IDs or idempotency keys are remembered; it must outlast every possible retry.
- Defense in depthW09 · Day 5Several independent layers of security controls (perimeter, network, application, data, monitoring), so one failure isn't a breach.
- Distributed lockW05 · Day 5A lock that holds across machines, usually from a coordination service, so only one process at a time does a piece of work.
- Distributed tracingW10 · Day 2Following one request across services: a trace is the whole journey, made of timed spans for each step, linked by a propagated trace ID.
- DNSW00 · Part 2The internet's phone book: it translates domain names like www.example.com into the IP addresses computers use.
- Dual-write problemW03 · Day 2Writing to two systems (the database and a message broker) in one operation without atomicity, so a crash can leave them disagreeing.
- Durable executionW05 · Day 3Workflow code whose progress is persisted step by step, so after a crash it resumes where it left off instead of starting over.
E
- Edge n-gramW07 · Day 4Indexing every prefix of a word (n, ni, nik, nike) so autocomplete becomes a fast exact lookup instead of a prefix scan.
- Ephemeral port exhaustionW00 · Part 4Running out of local ports for outbound connections because each one holds a port until TIME_WAIT expires.
- Error budgetW10 · Day 1The unreliability an SLO allows: at 99.9% over 30 days, 43.2 minutes of bad time to spend on releases and incidents.
- ETagW04 · Day 5A version tag on a response; the client sends it back in If-None-Match and gets a body-less 304 Not Modified when nothing changed.
- Event sourcingW00 · Part 6Storing every change as an immutable event and deriving current state by replaying them, instead of storing only the latest state.
- Event timeW08 · Day 4When something actually happened, versus processing time, when the pipeline saw it; analytics must aggregate by event time.
- Event-driven architectureW00 · Part 2Services emit events (OrderCreated) onto a bus and others react to them, instead of calling each other in a synchronous chain.
- Event-driven invalidationW04 · Day 2Publishing a change event when data is written, and having consumers delete or refresh the affected cache keys.
- Eventual consistencyW01 · Day 2If writes stop, all replicas eventually converge to the same value, with no promise about when.
- Exactly-once processingW00 · Part 6Each message's effect happens once; in practice at-least-once delivery plus idempotent or transactional processing.
- Expand-contract migrationW10 · Day 3Changing a schema in backward-compatible phases: add the new structure, migrate and dual-write, switch reads, then remove the old.
- Exponential backoffW02 · Day 3Waiting longer between each retry (1 s, 2 s, 4 s…) plus random jitter, so retries don't hammer a struggling service in lockstep.
F
- Faceted searchW07 · Day 4Showing filter options with counts (category, brand, price range) computed from the current results, refining as users click.
- Fail openW01 · Day 3What a protective component does when its own dependency fails: allow everything (fail open) or reject everything (fail closed).
- FailoverW01 · Day 2Replacing a failed primary: followers notice missed heartbeats, a new primary is promoted and clients are pointed at it.
- Fair schedulingW09 · Day 2Serving work round-robin across tenants (optionally weighted by plan) instead of first-come-first-served, so one tenant's flood can't starve others.
- FallbackW02 · Day 3A sensible default returned when a dependency fails or its circuit is open, such as a cached value or a safe score.
- Fan-out on readW04 · Day 4Building a feed at read time by fetching and merging recent posts from everyone the user follows.
- Fan-out on writeW04 · Day 4Pre-computing feeds when someone posts: the post is pushed into every follower's feed, making reads cheap and writes expensive.
- Feature flagW10 · Day 3A runtime switch that turns code paths on or off without a deploy, separating deployment from release.
- Fencing tokenW05 · Day 5A number that increases with every new leader or lock holder; resources reject requests carrying an older token than they've seen.
- Filter contextW07 · Day 3Search clauses that only say yes or no (no scoring) and can be cached, versus query clauses that compute relevance scores.
- Fixed window counterW01 · Day 3Counting requests per fixed time slot (each minute) and resetting at the boundary; simple, but allows up to 2× bursts across a boundary.
- Four golden signalsW10 · Day 1Latency, traffic, errors and saturation, the four signals to watch for any service; RED (rate, errors, duration) covers request-driven ones.
- Functional requirementsW00 · Part 1What the system does: the features users and admins rely on, such as uploading a photo or sending a message.
G
H
- Half-open stateW02 · Day 3The circuit breaker's testing state: after the open timeout a trial request goes through; success closes the circuit, failure reopens it.
- Hash chainW03 · Day 5Each log entry stores a hash covering the previous entry's hash, so changing any past entry breaks every hash after it.
- Hash partitioningW01 · Day 1Placing each key on partition hash(key) mod N: even spread and O(1) lookup, but no range queries.
- Head-of-line blockingW00 · Part 4When one lost or slow item at the front holds up everything queued behind it, such as packets waiting for a retransmission.
- Health checkW00 · Part 2A periodic probe (often GET /health) a load balancer uses to detect unhealthy servers and stop sending them traffic.
- HeartbeatW02 · Day 5A periodic 'still alive' signal; when heartbeats stop arriving, the node or job is presumed dead and its work reassigned.
- Hedged requestW02 · Day 1If a request hasn't answered by about the P95 time, send a duplicate to another server and use whichever replies first.
- High-level designW00 · Part 1The big-picture design: which components exist, how they connect, how data flows and why each technology was chosen.
- HMAC signatureW02 · Day 4A hash of the payload keyed with a shared secret, sent with a webhook so the receiver can check it is authentic and untampered.
- Horizontal scalingW00 · Part 6Adding more machines and spreading the load across them, instead of making one machine bigger.
- Hot keyW01 · Day 4A key that gets disproportionately more traffic than the rest, overwhelming the one partition or cache node that owns it.
- HTTP/2W00 · Part 4The HTTP version that multiplexes many request streams over one TCP connection and compresses headers (HPACK).
- Hybrid fan-outW04 · Day 4Push posts from regular users into feeds on write; pull celebrities' posts at read time and merge them in.
I
- IdempotencyW02 · Day 2An operation is idempotent if doing it many times has the same effect as doing it once.
- Idempotency keyW02 · Day 2A unique ID the client sends with each logical operation; the server stores it with the result and replays that result on retries.
- IncidentW10 · Day 5An unplanned disruption or degradation of service that needs an immediate response, graded by severity from SEV 1 (critical) to SEV 4.
- Incident commanderW10 · Day 5The single coordinator of an incident response: declares severity, assigns roles, makes decisions and keeps communication flowing.
- Index aliasW07 · Day 2A stable name pointing to a real index; reindex into a new index, then swap the alias atomically for a zero-downtime switch.
- Inverted indexW07 · Day 1A map from each term to the list of documents containing it, so a search looks up words instead of scanning every document.
- Isolation levelsW00 · Part 6How much concurrent transactions can see of each other: read uncommitted, read committed, repeatable read and serializable, weakest to strongest.
J
K
- Kappa architectureW08 · Day 2Streaming only: one stream processor over an immutable log with long retention; to reprocess, replay the log through a new version.
- Key saltingW01 · Day 4Splitting one hot logical key into several physical keys (key:0…key:9) on different partitions, then combining them on read.
L
- Lambda architectureW08 · Day 2Running a batch layer (accurate, periodic) and a speed layer (real-time, approximate) side by side and merging their results at query time.
- Last-write-winsW05 · Day 4Resolving conflicting writes by keeping the one with the highest timestamp and discarding the rest.
- Layer 4 vs Layer 7 load balancingW00 · Part 2L4 balancers route by IP and port without reading the payload; L7 balancers read HTTP and route by path, headers or cookies.
- Leader electionW05 · Day 5Nodes agreeing that exactly one of them is the leader that does the work, and choosing a new one when it fails.
- Leader-follower replicationW01 · Day 2One leader takes all writes and streams changes to followers (replicas); reads can go to the leader or any follower.
- Leaderless replicationW01 · Day 2No leader: clients write to and read from several replicas directly, and quorums decide when a write or read counts.
- Leaky bucketW01 · Day 3Requests queue in a bucket that drains at a fixed rate, smoothing bursts into a steady outflow; overflow is rejected.
- LeaseW05 · Day 5A time-limited grant of leadership or a lock that the holder must keep renewing; if renewals stop, it expires and someone else can take over.
- LinearizabilityW00 · Part 6The strongest consistency model: every operation appears to happen instantly at one point in real time between its start and finish.
- Little's lawW10 · Day 4Items in a system = arrival rate × time each spends there (L = λ × W): 100 requests/s at 200 ms means 20 in flight.
- Load balancerW00 · Part 2A component that spreads incoming traffic across many servers, for scale, availability (skip dead servers) and performance.
- Load sheddingW03 · Day 3Deliberately dropping or rejecting excess work, lowest priority first, so the system survives overload.
- Load testingW10 · Day 4Driving realistic synthetic traffic at a system to find its real limits and bottlenecks before production traffic does.
- Low-level designW00 · Part 1How each piece works inside: database schema, API contracts, classes and methods, algorithms, data structures and error handling.
- LRU evictionW00 · Part 6Evicting the entry that hasn't been used for the longest time when the cache is full; the usual default policy.
- LSM treeW00 · Part 6A write-optimised structure: writes go to an in-memory table, flush to sorted immutable files, and background compaction merges them.
M
- Materialized viewW08 · Day 5A stored, precomputed query result, such as hourly or daily rollups, refreshed as data changes, so dashboards read small tables.
- Message queueW03 · Day 1A buffer between producers and consumers; in a work queue each message goes to exactly one consumer.
- Metric cardinalityW10 · Day 2The number of distinct label combinations a metric has; unbounded labels such as user_id explode storage and cost.
- Metric typesW10 · Day 2Counters only go up, gauges go up and down, histograms bucket observations such as latencies, and summaries precompute quantiles.
- MicroservicesW00 · Part 2An architecture of small services, each owning one business capability and its data, deployed and scaled independently.
- Monotonic readsW01 · Day 2Once a user has seen a version of the data, later reads never show them an older version.
- Multi-leader replicationW01 · Day 2Several nodes (often one per region) accept writes and replicate to each other, so concurrent writes can conflict.
- Multi-tenancyW09 · Day 1One software instance serving many customers (tenants), each tenant's data and configuration isolated from the others.
- Multi-tier cachingW04 · Day 5Caching at several layers (browser, CDN, API gateway, application cache, database) so most requests stop as early as possible.
- Mutual TLSW00 · Part 4TLS where both sides present certificates: the server verifies the client too, so service identity is proven both ways.
N
- Noisy neighborW09 · Day 2A tenant whose heavy resource use slows down other tenants on the same shared infrastructure.
- Non-functional requirementsW00 · Part 1How well the system does its job: latency, availability, throughput, durability, security and compliance targets.
- Notification digestW06 · Day 3Collecting many small notifications into one scheduled summary ('20 people liked your post', a 6 p.m. daily digest) instead of sending each.
O
- Object storageW00 · Part 2Storage for files as objects in buckets (like S3), accessed over HTTP: virtually unlimited, very durable and cheap per GB.
- ObservabilityW10 · Day 2Understanding a system's behaviour from its outputs (metrics, logs, traces) well enough to answer questions you didn't anticipate.
- OLAPW08 · Day 3OLTP runs the business (many small row reads and writes); OLAP understands it (few big queries over many rows and few columns).
- Optimistic lockingW05 · Day 1Read a row's version, then update only if the version is unchanged, retrying on conflict; pessimistic locking locks the row first.
- OrchestrationW05 · Day 2Saga coordination by a central orchestrator that tells each service what to do next and runs compensations on failure.
- OSI modelW00 · Part 4A seven-layer vocabulary for networking, from physical links up to applications; system design mostly talks about layers 3, 4 and 7.
P
- P99 latencyW02 · Day 1The latency 99% of requests beat: percentiles describe the slow tail that averages hide.
- PACELCW00 · Part 6CAP extended: if partitioned, choose availability or consistency; else, even with no partition, choose latency or consistency.
- Page cacheW00 · Part 5The kernel's RAM cache of file pages: reads that hit it take microseconds instead of a trip to disk.
- Partition keyW01 · Day 1The field whose value decides which partition a record lives on, such as short_code or user_id.
- Partition pruningW08 · Day 5Splitting tables by a column (usually date) so a query's filter lets the engine skip every partition it can't need.
- Pivot transactionW05 · Day 2The saga step after which it must complete: earlier failures are compensated (backward recovery), later ones retried (forward recovery).
- Poison pillW03 · Day 4A message that fails every time it is processed, no matter how often it is retried, blocking or crashing its consumer.
- Principle of least privilegeW09 · Day 5Giving every person and service only the access it needs for its job, so a compromise exposes as little as possible.
- Priority isolationW06 · Day 4Separate queues and workers per priority, so a bulk campaign can never delay critical notifications such as OTPs or security alerts.
- Probabilistic early expirationW04 · Day 3Refreshing an entry at a random moment shortly before its TTL ends, so keys don't all expire at once.
- Publish-subscribeW03 · Day 1A messaging pattern where every message published to a topic is delivered to all of its subscribers.
Q
R
- Range partitioningW01 · Day 1Giving each partition a contiguous key range (A-F, G-L…): range queries stay on one partition, but hot ranges overload one.
- Rate limitingW01 · Day 3Capping how many requests a client may make per time window, and rejecting or delaying the excess.
- Read-through cacheW04 · Day 1The cache sits between the application and the database and loads missing entries itself; the app only talks to the cache.
- Read-your-writes consistencyW01 · Day 2A user always sees their own writes immediately, even if other users may still see stale data.
- Replication lagW01 · Day 2The delay between a write on the leader and that write appearing on a follower: milliseconds normally, minutes under load.
- Request coalescingW04 · Day 3Concurrent requests for the same missing key share one fetch from the source; the rest wait and reuse its result.
- Requests per secondW00 · Part 3Throughput as requests (or queries) handled each second; estimated as daily actions divided by 86,400, then sized for the peak.
- ReshardingW01 · Day 1Moving data when partitions are added or removed; with hash mod N nearly every key changes partition.
- Right to erasureW09 · Day 4A person's GDPR right (Article 17) to have their personal data deleted, which must reach every system holding it.
- Rolling deploymentW10 · Day 3Replacing old instances with new ones a few at a time, checking health before continuing, so there is no downtime.
- Row-level securityW09 · Day 1A database feature (as in PostgreSQL) that filters rows by policy, such as the session's tenant, so a query missing its WHERE can't leak data.
S
- SagaW05 · Day 2A distributed transaction as a sequence of local transactions, each with a compensating action that undoes it if a later step fails.
- Sequential consistencyW05 · Day 1Every node sees all operations in the same order, each client's in its own program order, though not necessarily in real-time order.
- Server-Sent EventsW00 · Part 4A one-way stream from server to browser over plain HTTP, with automatic reconnection built into the browser API.
- Session storeW01 · Day 5A shared, fast store (often Redis) for user sessions, so any stateless server can read a user's session by its ID.
- ShardingW01 · Day 1Splitting one dataset across machines (shards or partitions) so storage, throughput and memory add up beyond one server's limits.
- SLAW10 · Day 1Service level agreement: an external promise to customers about service levels, with consequences such as credits if it is broken.
- SLIW10 · Day 1Service level indicator: a measured number describing service behaviour, such as the share of requests served successfully under 200 ms.
- Sliding window counterW01 · Day 3Weighting the previous fixed window's count by how much it overlaps the sliding window, then adding the current count.
- Sliding window logW01 · Day 3Storing the timestamp of every request and counting those inside the last window: exact, but memory grows with traffic.
- SLOW10 · Day 1Service level objective: the internal target for an SLI over a window, such as 99.9% of requests succeeding over 30 days.
- Sloppy quorumW01 · Day 2When the usual replicas are down, writes go to other available nodes, which hold them and hand them back later (hinted handoff).
- Slowly changing dimensionW08 · Day 3How a dimension keeps history when attributes change; Type 2 adds a new row per change with valid_from, valid_to and is_current.
- Split brainW01 · Day 2Two nodes both believing they are the leader, for example after a network partition, so both accept conflicting writes.
- Stale-while-revalidateW04 · Day 3Serving the stale cached value immediately while refreshing it in the background, so no user waits on a miss.
- Star schemaW08 · Day 3A central fact table of measures (one row per event) with foreign keys to denormalised dimension tables you group and filter by.
- Stateless serviceW00 · Part 2A component that keeps no client or session state between requests, so any instance can serve any request and instances are interchangeable.
- Sticky sessionsW01 · Day 5The load balancer sends all of one user's requests to the same server, so session data can stay in that server's memory.
- Strong consistencyW01 · Day 2Every read returns the most recent write, and all clients see the same data at the same time.
- Structured loggingW10 · Day 2Writing logs as key-value records (JSON) with consistent fields such as trace_id and user_id, so they can be searched and aggregated.
- Synchronous replicationW01 · Day 2Sync: the leader waits for follower confirmation before acknowledging a write. Async: it acknowledges at once and replicates afterwards.
T
- TCP three-way handshakeW00 · Part 4SYN, SYN-ACK, ACK: the exchange that opens a TCP connection, costing one round trip before the first request can go.
- Tenant contextW09 · Day 1Knowing which tenant a request belongs to and carrying that tenant ID through every service, query, event and background job.
- Tenant quotaW09 · Day 2A per-tenant limit on rate, concurrency, volume, compute or features, usually tiered by plan, that caps how much one tenant can consume.
- Text analysisW07 · Day 1Turning text into index terms: character filters, a tokenizer, then token filters (lowercasing, stop words, stemming).
- Threat modelingW09 · Day 5Systematically listing what can go wrong at each trust boundary; STRIDE = spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
- Thundering herdW04 · Day 3Many requests at once hitting a missing or expired cache entry and all going to the database together, overwhelming it.
- Timeout budgetW02 · Day 1Dividing a request's total allowed time across its downstream calls, each getting what remains rather than a fixed full timeout.
- TLSW00 · Part 4Transport Layer Security: encrypts and authenticates a connection; the handshake checks the server's certificate and agrees session keys.
- Token bucketW01 · Day 3A bucket refills with tokens at a steady rate up to a cap; each request spends one, allowing controlled bursts up to the cap.
- TombstoneW05 · Day 4A marker recording that an item was deleted, kept so replicas and caches don't resurrect it from an older copy.
- Transactional outboxW03 · Day 2Writing the business change and its event to an outbox table in the same database transaction, then publishing the outbox to the broker.
- TTLW04 · Day 2Time-to-live: how long a cache entry (or record) is kept before it expires automatically.
- Tunable consistencyW05 · Day 1Choosing the consistency level per operation, such as Cassandra's ONE, QUORUM or ALL, or DynamoDB's strongly consistent reads.
- Two-phase commitW05 · Day 2A coordinator asks every participant to prepare, then tells all to commit (if all voted yes) or abort: atomic but blocking.
V
- Vary headerW04 · Day 5The cache key is what a cache stores a response under (URL + query by default); Vary adds request headers, like Accept-Encoding, to it.
- Vector clockW05 · Day 4A map of per-node counters attached to data that shows whether one version happened before another or both are concurrent.
- Versioned keysW04 · Day 2Putting a version in the cache key (product:123:v5) or asset URL; a change bumps the version, so readers move to a fresh key.
- Vertical scalingW00 · Part 6Making one machine bigger (more CPU, RAM, faster disks) to handle more load.
- Virtual nodesW01 · Day 1Placing each physical node at many points on the hash ring, so keys spread evenly and a removed node's load spreads widely.
W
- WatermarkW08 · Day 4A stream processor's declaration that all events up to event time W have (probably) arrived, so windows ending before W can close.
- WebhookW02 · Day 4An HTTP callback: when an event happens, your system POSTs it to a URL someone registered, instead of them polling you.
- WebSocketW00 · Part 4A protocol that upgrades an HTTP connection into a long-lived, two-way channel, so server and client can push messages any time.
- WindowingW08 · Day 4Grouping a stream into time windows: tumbling (fixed, non-overlapping), sliding (overlapping) or session (closed after an inactivity gap).
- Write amplificationW04 · Day 4One logical write causing many physical or downstream writes, such as one post fanned out to millions of feeds.
- Write-ahead logW00 · Part 5An append-only log every change is written and fsynced to before the data files are updated, so a crash can be replayed safely.
- Write-behind cacheW04 · Day 1Writes go to the cache immediately and are flushed to the database asynchronously, often batched; fast, but unflushed writes can be lost.
- Write-through cacheW04 · Day 1Writes go to the cache, which synchronously writes them to the database, so cache and database stay in step.