/wiki / system-design

System Design — Map of Content

2026-09-02T00:00:00.000Z

Map of Content for System Design — 40 concepts. Start here to navigate system-design.

Core Concepts

Active-Active Failover — concept
Active-Passive Failover — concept
AP — Availability and Partition Tolerance — concept
Availability Nines — concept
Availability in Parallel vs Sequence — concept
Back-of-the-Envelope Estimates — concept
Back Pressure — concept
Cache-Aside — concept
CAP Theorem — concept
Pull CDN — concept
Push CDN — concept
CP — Consistency and Partition Tolerance — concept
Database Federation — concept
Denormalization — concept
DNS in System Design — concept
Eventual Consistency — concept
Horizontal Scaling — concept
Latency vs Throughput — concept
Layer 4 Load Balancing — concept
Layer 7 Load Balancing — concept
load-balancer-vs-reverse-proxy — concept
Master-Master Replication — concept
Master-Slave Replication — concept
Message Queues — concept
Microservices Architecture — concept
NoSQL Database Types — concept
Performance vs Scalability — concept
Refresh-Ahead Cache — concept
REST (Architectural Style) — concept
Reverse Proxy Pattern — concept
RPC (Remote Procedure Call) — concept
Service Discovery — concept
Sharding — concept
SQL Tuning — concept
sql-vs-nosql — concept
Strong Consistency — concept
Task Queues — concept
Weak Consistency — concept
Write-Behind Cache — concept
Write-Through Cache — concept

Mechanisms & How Things Work

Auto-generated — edit to curate. Pages that explain processes/flows.

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

active-active-failover

2026-05-15T00:00:00.000Z

The Problem

Standby servers in active-passive setups remain idle, wasting compute resources and providing no return on the hardware investment.

Core Idea

In active-active failover, both servers manage traffic simultaneously, spreading the load between them and eliminating idle resources.

How It Works

Both servers are active and handle client requests concurrently.
A load balancer or DNS distributes incoming traffic across both servers.
If one server fails, the remaining server continues handling all traffic (with degraded capacity).
DNS must be configured with both IP addresses for public-facing services.
Application logic must be aware of both servers for internal communication.
Also called master-master failover.

Visual Explanation

Key Properties

No idle resources — both servers handle traffic
Load is spread between both servers, improving throughput
DNS or application must be aware of both server IPs
Capacity is degraded (not lost) on single-server failure
Also called master-master failover

Connections

Contrasts with: Active-Passive Failover — both active vs one standby
Related: Availability Nines — active-active improves overall availability
Related: Layer 4 Load Balancing — load balancers distribute traffic in active-active
Related: Horizontal Scaling — active-active is a form of horizontal scaling

Edge Cases & Gotchas

Session affinity (sticky sessions) becomes harder — requests from one user may hit different servers
Both servers must have consistent state or share storage to avoid data divergence
Failover capacity is only 50% — if one server dies, the remaining server must handle full load

active-passive-failover

2026-05-15T00:00:00.000Z

The Problem

A single server is a single point of failure — if it goes down, the service becomes unavailable. Unplanned downtime leads to revenue loss, user trust erosion, and SLA violations.

Core Idea

Active-passive failover uses a standby server that takes over if the active server fails, with heartbeat monitoring detecting failure and triggering the switch.

How It Works

The active server handles all production traffic while the passive server remains idle.
Heartbeat signals are sent between the active and passive servers at regular intervals.
If the passive server stops receiving heartbeats, it assumes the active has failed.
The passive server takes over the active server’s IP address (via IP takeover or virtual IP).
The passive resumes service from the point the active left off (with shared storage).
Downtime depends on the standby type: hot standby (minutes) vs cold standby (hours).

Visual Explanation

Key Properties

Passive server sits on standby, handling zero traffic during normal operation
Only the active server handles client requests
Heartbeat-based failure detection triggers automatic failover
Also called master-slave failover
Failover time varies by standby type: hot (minutes) vs cold (hours)

Connections

Contrasts with: Active-Active Failover — passive standby vs both serving traffic
Related: Availability Nines — failover improves uptime percentage
Related: Layer 4 Load Balancing — load balancers orchestrate failover routing
Related: Horizontal Scaling — adding passive nodes is a scaling concern

Edge Cases & Gotchas

Split-brain scenario: both servers think the other is dead and both become active, causing data corruption
Heartbeat network itself can be a single point of failure — redundant heartbeat links recommended
Stateful services (in-memory sessions) are lost on failover unless backed by shared storage

ap-availability-partition-tolerance

2026-05-15T00:00:00.000Z

The Problem

Some systems must remain operational during network partitions, even if the data served might be stale. Social media feeds, content delivery, and collaborative tools cannot show errors to users.

Core Idea

AP systems choose availability over consistency during network partitions. Every request receives a response using the most readily available version of the data. Writes are accepted and propagated asynchronously — when the partition resolves, nodes reconcile any conflicts. The system is always responsive but may serve stale or divergent data temporarily.

How It Works

Pre-partition: Nodes replicate data asynchronously. A write to one node is propagated to others in the background. Reads may return slightly stale data.
Partition occurs: A subset of nodes becomes unreachable. Each partition group continues operating independently.
Serve what you have: Reachable nodes accept reads and writes using local data. No request is refused.
Conflict resolution: When the partition heals, nodes exchange write logs. Conflicting writes are resolved using a strategy (last-write-wins, CRDT merge, application-level reconciliation).
Convergence: All nodes eventually converge to the same state.

Visual Explanation

Key Properties

Always returns a response: No request is rejected or timed out due to consistency concerns
May return stale data: Reads reflect the latest write the responding node has seen, which may lag behind
Writes eventually propagate: Asynchronous replication means write conflicts are resolved post-facto
Common in social media, CDNs, DNS: Applications where availability matters more than absolute consistency

Connections

Built from: CAP Theorem
Contrasts with: CP — Consistency and Partition Tolerance
Related: Eventual Consistency — AP systems implement eventual consistency
Related: Push CDN — an AP system that serves content despite partitions

Edge Cases & Gotchas

Conflict resolution is hard: Last-write-wins can silently discard data. CRDTs avoid data loss but are complex to implement. Application-level merging (e.g., collaborative editing) may require user intervention.
Stale reads can compound: If many reads traverse a chain of eventually-consistent replicas, staleness can accumulate beyond expected bounds.
Not appropriate for all data: Financial transactions, inventory counts, and lock services generally cannot tolerate AP behavior.

availability-nines

2026-05-15T00:00:00.000Z

The Problem

Uptime guarantees need a standardized measurement to compare systems and set meaningful SLAs between providers and customers.

Core Idea

Availability is quantified by uptime percentage — “number of 9s” (99.9% = three 9s, 99.99% = four 9s). Each additional 9 represents a tenfold reduction in allowed downtime.

How It Works

Availability is calculated as uptime divided by total time over a measurement period.
99.9% (three 9s) permits approximately 8 hours 45 minutes of downtime per year.
99.99% (four 9s) permits approximately 52 minutes of downtime per year.
99.999% (five 9s) permits approximately 5 minutes of downtime per year.
Each additional 9 requires exponentially more redundancy and operational discipline.

Visual Explanation

Key Properties

Measured in “number of 9s” — 99.9%, 99.99%, 99.999%
Each additional 9 is a 10x reduction in allowed downtime
Three 9s = 99.9% uptime
Four 9s = 99.99% uptime
Five 9s = 99.999% uptime

Connections

Built from: Availability in Parallel vs Sequence — how component availability combines to produce overall nines
Related: Active-Passive Failover — failover pattern increases achievable nines
Related: Active-Active Failover — active-active improves achievable nines
Related: Horizontal Scaling — adding nodes increases availability through redundancy

Edge Cases & Gotchas

Nines are calculated over a full year — a single prolonged outage can blow through the entire budget
“Five 9s” is extraordinarily difficult in practice, requiring redundant everything (power, network, servers, data centers)
Partial outages (degraded but not down) are often excluded from SLA calculations, masking real availability

availability-parallel-vs-sequence

2026-05-15T00:00:00.000Z

The Problem

When a system has multiple components, overall availability depends on how they are connected. Naively combining component availability gives misleading results.

Core Idea

Components in sequence multiply their availability together (making total availability worse), while components in parallel multiply their unavailability together (making total availability dramatically better).

How It Works

Sequence formula: Avail(Total) = Avail(A) × Avail(B). Two 99.9% components in series yield 99.8% — worse than either alone.
Parallel formula: Avail(Total) = 1 - (1 - Avail(A)) × (1 - Avail(B)). Two 99.9% components in parallel yield 99.9999% — better than either alone.
Parallel systems only fail if both (or all) redundant components fail simultaneously.

Visual Explanation

Key Properties

Sequential components multiply availability — total is always worse than the worst component
Parallel components multiply unavailability — total is always better than the best component
Fundamental principle underlying all reliability engineering and redundancy design

Connections

Builds into: Availability Nines — the formula behind nines calculations
Related: Active-Passive Failover — parallel arrangement of servers for failover
Related: Active-Active Failover — parallel arrangement for load sharing and redundancy
Related: Horizontal Scaling — adding parallel nodes improves overall system availability

Edge Cases & Gotchas

Components are rarely perfectly independent — shared power supplies, network links, or data centers create common-mode failures that violate the parallel model
The parallel formula assumes instant failover, but real failover has non-zero downtime that reduces effective availability
Very long dependency chains (many sequential components) degrade availability drastically — a system with ten 99.9% components in series is only 99.0% available

back-of-envelope-estimates

2026-05-15T00:00:00.000Z

The Problem

System design interviews and architecture decisions require quick quantitative estimates to determine whether a design is feasible — how much storage is needed, how many servers are required, what the bottleneck will be — without access to calculators or reference systems.

Core Idea

Back-of-the-envelope estimation uses powers of two for data sizing (2^10 = 1024 ≈ 1K, 2^20 ≈ 1M, 2^30 ≈ 1G) and known latency numbers (L1 cache 0.5ns, RAM 100ns, SSD 150μs, HDD 10ms, datacenter round-trip 500μs) to quickly approximate capacity, throughput, and performance of a system design.

How It Works

Powers of Two: memorize the table: 2^10 = 1K, 2^20 = 1M, 2^30 = 1G, 2^40 = 1T. Use these to estimate storage: a 4-byte integer, 1KB text document, 1MB image, etc.
Latency Numbers: memorize the approximate time each operation takes — L1 cache reference (0.5ns), branch mispredict (5ns), L2 cache reference (7ns), mutex lock/unlock (100ns), main memory reference (100ns), compress 1KB with Zippy (10μs), send 2KB over 1 Gbps (20μs), SSD random read (150μs), disk seek (10ms), datacenter round trip (500μs).
Combine: for a given design, multiply the per-operation cost by the request volume. Example: 10M daily active users, each generating 100 requests/day = 1B requests/day ≈ 12K requests/sec. Then multiply by per-request CPU/memory/IO to estimate total resources.

Visual Explanation

Key Properties

2^10 = 1024 ≈ 1000 (K) — approximate for quick estimation
2^20 ≈ 1 million (M) — typical for DAU and QPS estimates
2^30 ≈ 1 billion (G) — typical for storage estimates
Memory is 80,000x faster than disk — 100ns RAM vs 10ms HDD seek
Datacenter round-trip dominates — 500μs is 5,000x slower than a RAM access

Connections

Related: Performance vs Scalability — estimates quantify both dimensions: latency measures performance, throughput measures scalability
Related: Latency vs Throughput — estimates use latency numbers to compute throughput bounds
Related: Horizontal Scaling — estimates determine how many nodes are needed to achieve target throughput
Related: Availability Nines — estimates help calculate uptime requirements and redundant capacity
Related: Cache-Aside — latency estimates reveal when caching is necessary (disk reads at 10ms vs cache at 100ns)

Edge Cases & Gotchas

Orders of magnitude matter, exact numbers don’t — if your estimate is off by 2x, that’s fine; if it’s off by 100x, the design is likely infeasible.
Latency numbers are for the median — p99 latency can be 10-100x worse due to GC pauses, network jitter, and queueing; always add headroom.
Throughput ≠ latency — a system can handle 10K QPS (good throughput) but have 500ms p99 latency (bad); estimate both independently.

back-pressure

2026-05-15T00:00:00.000Z

The Problem

Unbounded queue growth under high load causes memory exhaustion, increased cache misses, and eventual system collapse. Without limits, backlog accumulates faster than workers can drain it.

Core Idea

Back pressure limits the size of a queue to maintain throughput and response times for already-accepted work. When the queue reaches its configured capacity, new requests are rejected — typically with HTTP 503 (Service Unavailable) — and clients retry with exponential backoff.

How It Works

Set a maximum queue size based on memory and throughput constraints.
When the queue reaches this limit, reject new incoming requests.
Return HTTP 503 Service Unavailable to the client.
Client retries using exponential backoff (1s, 2s, 4s, 8s… with jitter).
Throughput for already-queued jobs is preserved — the system degrades gracefully instead of collapsing.

Visual Explanation

Key Properties

Prevents memory exhaustion from unbounded queue growth
Maintains throughput for jobs already accepted into the queue
Rejected clients receive well-defined HTTP 503 responses
Exponential backoff with jitter prevents thundering herd on retry
Preserves overall system stability by shedding load at the boundary

Connections

Related: Message Queues — back pressure protects message queues from overload
Related: Task Queues — back pressure prevents task queues from growing unboundedly
Related: Latency vs Throughput — back pressure maintains stable throughput by rejecting excess load
Related: Horizontal Scaling — sustained back pressure is a signal to scale out the worker pool

Edge Cases & Gotchas

Retry storms: Without jitter, all clients retry simultaneously, creating a thundering herd on the queue. Always add random jitter to backoff intervals.
Queue sizing: Too small a queue underutilizes workers; too large defeats the purpose. Size based on expected worker drain rate and acceptable latency.
No back pressure on workers: If workers themselves slow down (e.g., due to DB contention), back pressure at the queue level doesn’t protect upstream resources.

cache-aside

2026-05-15T00:00:00.000Z

The Problem

Databases are slow for frequently accessed data. Pre-loading all possible data into cache proactively wastes memory and is impractical at scale.

Core Idea

Cache-aside (lazy loading) puts the application in charge of the cache — it loads data into cache on demand only when a cache miss occurs. The application checks the cache first, falls back to the database on a miss, and populates the cache for subsequent reads.

How It Works

Application checks cache for the requested entry.
If found (cache hit), return the data immediately.
If not found (cache miss), load the data from the database.
Store the retrieved data in the cache with a TTL.
Return the data to the caller.
Subsequent requests for the same key will hit the cache until the TTL expires.

Memcached is typically used in this pattern. Only data that is actually requested ends up in the cache.

Visual Explanation

Key Properties

Application manages cache lifecycle explicitly
Lazy loading — only requested data is cached (on-demand)
Cache does not interact with the database directly
Each cache miss costs 3 round trips (check cache, load DB, write cache)
Avoids filling cache with unused data, keeping memory efficient

Connections

Contrasts with: Write-Through Cache — lazy vs eager write
Contrasts with: Write-Behind Cache — synchronous vs async write
Related: Pull CDN — similar on-demand pull pattern
Related: Refresh-Ahead Cache — proactive vs reactive refresh

Edge Cases & Gotchas

Cache stampede: If many requests miss simultaneously (e.g., after TTL expiry), all hit the database at once. Mitigate with mutex locks or early recomputation.
Stale data: If the database is updated directly (bypassing cache), the cache serves stale data until TTL expiry.
Thundering herd: A popular key’s TTL expiry can trigger a database overload from concurrent misses.

cap-theorem

2026-05-15T00:00:00.000Z

The Problem

Distributed systems must handle network partitions (when nodes cannot communicate). Designers need a framework to reason about what properties a distributed system can guarantee under such failures.

Core Idea

The CAP Theorem states that a distributed data store can simultaneously provide at most two of three guarantees: Consistency (every read receives the most recent write or an error), Availability (every request receives a non-error response), and Partition Tolerance (the system continues operating despite arbitrary network failures). Since network partitions are inevitable, designers effectively choose between CP (Consistency + Partition Tolerance) and AP (Availability + Partition Tolerance).

How It Works

Normal operation: All three properties are satisfied — nodes communicate, reads are consistent, responses are returned.
Partition occurs: Network failure splits nodes into groups that cannot communicate.
CP choice: The system refuses responses from nodes that cannot be confirmed as consistent — returns errors or timeouts until the partition heals.
AP choice: The system returns whatever data is available from reachable nodes, accepting that data may be stale. Writes are queued and merged when the partition resolves.

Visual Explanation

Key Properties

C (Consistency): Every read receives the most recent write or an error
A (Availability): Every request receives a (non-error) response, without guarantee it contains the latest write
P (Partition Tolerance): The system continues to function despite network partitions
P is mandatory in distributed systems — networks are unreliable by nature
CA is a theoretical option that only applies to single-node systems or systems that can guarantee no network faults

Connections

Builds into: CP — Consistency and Partition Tolerance
Builds into: AP — Availability and Partition Tolerance
Related: Strong Consistency — guaranteed in CP systems
Related: Eventual Consistency — used in AP systems

Edge Cases & Gotchas

PACELC extension: CAP only considers partitions. PACELC adds that even without a partition (Else), there’s a latency-consistency trade-off. Most systems don’t operate in partition mode.
CA is misleading: Single-node systems aren’t distributed. Therefore, real distributed systems are either CP or AP.
Partition recovery is not automatic: When a partition heals, reconciliation logic is needed — stale writes may conflict, and resolution strategies (last-write-wins, CRDTs, etc.) must be in place.

cdn-pull

2026-05-15T00:00:00.000Z

The Problem

Pre-pushing all content to a CDN is wasteful if much of the content is rarely accessed, filling CDN storage with cold data.

Core Idea

Pull CDNs grab content from the origin server on the first user request, cache it at the edge with a TTL, and serve subsequent requests from cache.

How It Works

A user requests content that is not yet cached at the nearest CDN edge.
The CDN edge pulls the content from the origin server.
The edge caches the content and serves it to the user.
Subsequent requests for the same content are served directly from the edge cache.
The cached content expires based on its TTL or is evicted by a cache replacement policy.
Best suited for high-traffic sites with long-tail content access patterns.

Visual Explanation

digraph pull_cdn {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica" fontsize=12]
  edge [fontname="Helvetica" fontsize=10]
 
  USER1 [label="First User Request"]
  USER2 [label="Subsequent Users"]
  EDGE [label="CDN Edge Node" fillcolor="#d4edda"]
  ORIGIN [label="Origin Server" fillcolor="#ffe5cc"]
 
  USER1 -> EDGE [label="cache miss"]
  EDGE -> ORIGIN [label="pull from origin"]
  ORIGIN -> EDGE [label="serve content"]
  EDGE -> USER1 [label="serve & cache"]
  USER2 -> EDGE [label="cache hit"]
  EDGE -> USER2 [label="serve from cache"]
}

Key Properties

First-request-triggered caching — content is pulled on demand
TTL-based expiration controls how long content stays cached
Minimizes CDN storage costs — only accessed content is stored
Slower first request (cache miss penalty) vs fast subsequent requests
Best suited for high-traffic sites with diverse content

Connections

Contrasts with: Push CDN — lazy-pull vs proactive-push content delivery
Related: DNS in System Design — DNS routing directs users to the CDN edge
Related: Cache-Aside — pull CDN follows the same lazy-loading pattern as cache-aside
Related: Reverse Proxy — pull CDN is a geographically distributed reverse proxy

Edge Cases & Gotchas

Thundering herd problem: if popular content expires simultaneously, a flood of origin requests hits the server
Pull CDNs contribute to origin traffic on first access — large content (videos) causes significant origin load on first requests
TTL tuning is critical — too short defeats caching, too long serves stale content

cdn-push

2026-05-15T00:00:00.000Z

The Problem

Serving all content from a single origin server creates latency for distant users and places heavy load on the origin infrastructure.

Core Idea

Push CDNs receive new content whenever changes occur on the server — the server proactively uploads content to the CDN edge nodes.

How It Works

When content is created or updated on the origin server, the server uploads it to the CDN.
The CDN distributes the content to its edge nodes worldwide.
URLs in the application are rewritten to point to the CDN endpoint.
User requests hit the nearest CDN edge, which serves the pre-pushed content.
Content expires from the CDN based on a configured TTL or is explicitly invalidated.
Best suited for sites with low traffic or content that changes infrequently.

Visual Explanation

Key Properties

Server-initiated content push — origin decides what to upload
Full responsibility for content distribution lies with the origin server
Content is uploaded only when it changes (not on every request)
Minimizes origin traffic but may waste CDN storage for rarely accessed content
Best suited for low-traffic sites or content with predictable access patterns

Connections

Contrasts with: Pull CDN — server-push vs lazy-pull content delivery strategies
Related: DNS in System Design — DNS directs clients to the nearest CDN edge
Related: Reverse Proxy — both serve cached content closer to users

Edge Cases & Gotchas

Cache invalidation is difficult — if content needs to be removed, you must explicitly purge it from all CDN edges
Pushing content that nobody ever requests wastes CDN storage
If the push mechanism fails, stale content remains served until manually invalidated

cp-consistency-partition-tolerance

2026-05-15T00:00:00.000Z

The Problem

When a network partition occurs, the system must decide whether to return potentially stale data or refuse to respond. Applications like banking and inventory management cannot tolerate stale reads.

Core Idea

CP systems choose consistency over availability during network partitions. When nodes cannot verify they have the latest data, the system returns errors or times out rather than serving stale data. Consistency is guaranteed at all times, but availability is sacrificed during partitions.

How It Works

Pre-partition: All nodes agree on the latest write. Reads go to any node and return the same value. Writes must be acknowledged by a majority/quorum before the client receives confirmation.
Partition occurs: A subset of nodes becomes unreachable. The reachable nodes cannot confirm whether the isolated nodes have accepted a newer write.
Reject to be safe: The reachable nodes refuse reads (return error or timeout) because they cannot guarantee the returned value is the most recent write.
Partition heals: Nodes re-establish communication. Reconciliation replays any writes that were accepted by the isolated minority. The system resumes full operation.

Visual Explanation

Key Properties

Atomic consistent reads: Every read returns the latest write or an error — never stale data
May return errors during partition: Availability drops to zero for the affected data
Business-critical use cases: Banking, inventory, booking systems where stale data causes real harm
Synchronous replication: Writes are synchronously replicated to a quorum before acknowledgment

Connections

Built from: CAP Theorem
Contrasts with: AP — Availability and Partition Tolerance
Related: Strong Consistency — CP systems guarantee strong consistency
Related: Master-Slave Replication — reading from master ensures strong consistency (a CP pattern)

Edge Cases & Gotchas

Quorum failure: If a majority of nodes are lost during partition, the system becomes read-only or entirely unavailable until the partition resolves.
Tail latency in normal operation: The synchronous replication quorum means the slowest node in the quorum determines write latency.
Not all CP is equal: Some CP systems (e.g., ZooKeeper) prioritize partition recovery speed, while others (e.g., traditional RDBMS with sync replication) may remain unavailable for longer.

database-federation

2026-05-15T00:00:00.000Z

The Problem

A single monolithic database handling all application functions (users, products, forums, analytics) creates bottlenecks. It becomes a shared contention point for writes, its replication lag affects every feature, and a schema change for one domain risks affecting unrelated features.

Core Idea

Federation splits databases by business function — forums, users, and products each get their own dedicated database. This reduces write contention, shrinks replication lag, improves cache locality, and allows each database to be tuned for its specific workload.

How It Works

Identify functional domains in the application (e.g., users, products, forums, analytics).
Create a separate database instance for each domain.
Route all reads and writes for a domain to its dedicated database.
Each database operates independently — its own replication topology, backup schedule, and schema.
Application logic or an API gateway determines which database to query based on the operation.
Cross-database queries are handled in application code (two separate queries joined in memory).

Visual Explanation

Key Properties

Function-based splitting — each database owns a distinct business domain
Smaller databases — less data per DB means faster backups, lower replication lag
Reduced contention — writes to users don’t block writes to products
More cache hits — domain-specific working sets fit better in memory
Requires application routing — the application layer must know which DB to query

Connections

Related: Sharding — federation splits by function, sharding splits by key (both are forms of data partitioning)
Contrasts with: monolithic database — single shared DB vs multiple function-specific DBs
Related: Denormalization — often needed with federation since cross-DB joins are impractical
Related: Microservices Architecture — the database-per-service pattern is a natural fit for microservices
Related: Master-Slave Replication — each federated database can have its own replication topology

Edge Cases & Gotchas

Cross-domain queries — a report that needs user names and product names requires two database queries and application-level join, which is slower than a SQL JOIN.
Uneven load distribution — one domain (users) may have 100x the traffic of another (analytics), requiring different infrastructure per federation.
Transaction boundaries — an operation that updates both users and forums cannot use a cross-database ACID transaction; requires a saga or eventual consistency pattern.

denormalization

2026-05-15T00:00:00.000Z

The Problem

Complex SQL joins across normalized tables become prohibitively expensive as data grows — especially when joins span shards, federated databases, or high-traffic tables. These joins add milliseconds to query time, which compounds under load.

Core Idea

Denormalization intentionally adds redundant copies of data across multiple tables to avoid expensive joins at read time. This improves read performance at the cost of write performance — reads become fast single-table lookups, but writes must update multiple copies of the data.

How It Works

Profile query patterns to identify frequent, expensive joins.
Add redundant columns to tables that are frequently joined together (e.g., store username in the orders table instead of joining users).
On write operations, update all copies of the redundant data — either in application code or via database triggers.
Use materialized views (PostgreSQL, Oracle) that automatically refresh the denormalized result set on a schedule or on change.
Monitor consistency — periodic reconciliation jobs can detect and fix diverging copies.

Visual Explanation

Key Properties

Improves read performance — single-table lookups instead of multi-table joins
Adds data redundancy — the same information exists in multiple places
Writes become more expensive — every write must update all redundant copies
Constraints help maintain consistency — foreign keys and check constraints reduce drift
Materialized views automate management — database-native denormalization with refresh schedules

Connections

Related: SQL Tuning — denormalization is a specific SQL optimization technique
Related: Sharding — denormalization avoids expensive cross-shard joins by colocating related data
Related: Database Federation — reduces the need for cross-database joins by duplicating reference data
Contrasts with: normalized schema — third-normal-form (3NF) eliminates redundancy; denormalization reintroduces it intentionally
Related: NoSQL Database Types — NoSQL databases are inherently denormalized; joins are done in application code

Edge Cases & Gotchas

Data drift — if one copy of the data is updated but another is not, queries return inconsistent results; write atomicity is critical.
Storage bloat — redundant copies increase disk usage; factor in at least 2x–3x storage for heavily denormalized schemas.
Update anomaly complexity — a single logical change (user changes their name) may need to update dozens of denormalized copies across multiple tables or databases.

dns-system-design

2026-05-15T00:00:00.000Z

The Problem

Users cannot remember numerical IP addresses for every service they access. A human-readable naming system that scales globally is needed.

Core Idea

DNS translates domain names (www.example.com) to IP addresses using a hierarchical, distributed system of name servers with caching at every level.

How It Works

A user types a domain name into a browser.
The browser checks its local cache, then the OS cache, then the ISP resolver.
The recursive resolver queries the root name server for the TLD server.
The TLD server directs to the authoritative name server for the domain.
The authoritative server returns the IP address (A record) or other record type.
Results are cached at each level for the duration of the TTL.
Record types include A (address), CNAME (canonical name), MX (mail exchange), NS (name server).

Visual Explanation

Key Properties

Hierarchical tree structure: root → TLD → authoritative
Cached at multiple levels: browser, OS, ISP resolver
TTL (Time To Live) controls how long entries are cached
Supports weighted routing, latency-based routing, and geo-routing via managed DNS providers
Managed DNS services: Route53, CloudFlare DNS, Google Cloud DNS

Connections

Related: Push CDN — DNS routes users to the nearest CDN edge server
Related: Pull CDN — DNS resolution directs users to the appropriate CDN endpoint
Related: Layer 4 Load Balancing — DNS can distribute traffic across multiple server IPs
Related: Active-Active Failover — DNS must be configured with all active server IPs

Edge Cases & Gotchas

DNS propagation delays mean changes to records take time (up to 48 hours for TTL expiration everywhere)
DNS is vulnerable to cache poisoning attacks if DNSSEC is not implemented
CNAME records cannot coexist with other record types at the same DNS node — use ALIAS or ANAME records instead

eventual-consistency

2026-05-15T00:00:00.000Z

The Problem

Strong consistency limits availability and throughput because it requires synchronous coordination before every read. Many applications can tolerate temporary inconsistency in exchange for higher availability and lower latency.

Core Idea

After a write, reads will eventually see it — typically within milliseconds — as data is replicated asynchronously across nodes. The system guarantees convergence: given enough time without new writes, all replicas will hold the same value. Between the write and convergence, reads may return stale data.

How It Works

Client writes to one node: The write is acknowledged immediately without waiting for replicas. The write is placed in a replication log.
Asynchronous propagation: The replication log is streamed to other nodes in the background. Propagation delay depends on network latency, load, and batch size.
Stale reads during window: A read to a node that hasn’t received the replication log returns the old value.
Convergence: Once all replicas have processed the log, every read returns the latest write. If no new writes occur, the system becomes consistent.

Visual Explanation

Key Properties

Convergence guaranteed: Given no new writes, all replicas will eventually hold the same value
Asynchronous replication: Writes are acknowledged immediately; replication happens in the background
Temporary inconsistency window: Brief period between write and full propagation where stale reads are possible
Works in DNS (TTL propagation), email (SMTP delay), and many NoSQL databases (DynamoDB, Cassandra)

Connections

Contrasts with: Strong Consistency — sync vs async replication, guarantees vs temporary inconsistency
Contrasts with: Weak Consistency — eventual guarantees convergence, weak does not
Related: AP — Availability and Partition Tolerance — AP systems use eventual consistency as their consistency model
Related: Master-Slave Replication — slaves are eventually consistent with the master
Related: DNS in System Design — DNS uses eventual consistency with TTL-based caching

Edge Cases & Gotchas

Write conflicts: Concurrent writes to different replicas may produce conflicts that require reconciliation (last-write-wins, CRDTs, application-level merging).
Staleness bounds are application-defined: DNS uses TTLs to bound inconsistency. Without explicit bounds, staleness can grow arbitrarily under heavy load or network issues.
Read-your-write consistency is not guaranteed: A client that writes to one node and immediately reads from another may not see its own write. Session consistency or quorum reads can mitigate this.

horizontal-scaling

2026-05-15T00:00:00.000Z

The Problem

Vertical scaling (buying a bigger server) hits diminishing returns — costs grow super-linearly while performance gains taper off, and high-end hardware requires specialized expertise.

Core Idea

Horizontal scaling adds more commodity machines to distribute load across them, improving both performance and availability through parallelism and redundancy.

How It Works

Clone identical server instances behind a load balancer.
Servers must be stateless — no user data stored locally on any instance.
Session data is stored in a centralized, shared store (Redis, Memcached, database).
The load balancer distributes incoming requests across all available instances.
More instances are added during traffic spikes and removed during lulls (auto-scaling).
Commodity hardware costs less than equivalent vertical upgrades and is easier to hire for.

Visual Explanation

Key Properties

Scales out by adding more machines (contrast: scaling up = bigger machine)
Requires a load balancer to distribute traffic
Servers must be stateless — user sessions live in an external store
More cost-effective than vertical scaling at medium to large scale
Higher availability than a single server — failure of one instance doesn’t take down the system

Connections

Related: Layer 4 Load Balancing — load balancers are the entry point that enables horizontal scaling
Related: Layer 7 Load Balancing — L7 LB enables routing to specific horizontally scaled services
Related: Active-Active Failover — active-active is a specific form of horizontal scaling
Related: Availability in Parallel vs Sequence — horizontal scaling improves availability through parallel redundancy

Edge Cases & Gotchas

Statelessness is hard for legacy applications that assume local file system access or in-memory session state
Auto-scaling can cause thundering herds if new instances all hit the database simultaneously on startup
Horizontal scaling does not help with database writes — those require sharding or read replicas

latency-vs-throughput

2026-05-15T00:00:00.000Z

The Problem

Low latency and high throughput are often competing goals — optimizing for one can degrade the other. Systems must balance both based on application requirements.

Core Idea

Latency is the time taken to complete a single operation (e.g., one HTTP request). Throughput is the number of operations completed per unit time (e.g., requests per second). A system can have low latency but low throughput, or high latency but high throughput.

How It Works

Single request measurement: Measure the time from request initiation to response completion (latency).
Aggregate measurement: Count completed requests over a fixed time window (throughput).
Pipeline effect: With a queue and multiple workers, each request’s latency may increase slightly while total throughput rises significantly.
Trade-off tuning: Increasing concurrency boosts throughput up to a point, beyond which contention causes latency to spike.

Visual Explanation

Key Properties

Latency measured in milliseconds or nanoseconds (time per operation)
Throughput measured in requests per second or operations per second
Goal: maximize throughput while keeping latency within acceptable bounds
Little’s Law: L = λ × W — average concurrency equals throughput times latency

Connections

Related: Performance vs Scalability — latency and throughput are the two dimensions of performance
Related: Back Pressure — queue sizing affects both latency and throughput
Related: Pull CDN — reduces latency by serving content from edge locations
Related: Message Queues — improves throughput by decoupling producers and consumers

Edge Cases & Gotchas

Tail latency matters: Average latency hides outliers. P99 latency spikes often cause user-perceived slowness even when the average looks fine.
Throughput vs bandwidth: Throughput is completed operations; bandwidth is capacity. You can have high bandwidth but low throughput due to protocol overhead or lock contention.
Coordinated omission: If you exclude slow requests from measurements, reported latency looks artificially low — a common benchmarking mistake.

layer4-load-balancing

2026-05-15T00:00:00.000Z

The Problem

A single server can be overwhelmed by traffic. Requests need to be distributed across multiple servers, but inspecting application-level content is expensive and unnecessary for basic distribution.

Core Idea

Layer 4 load balancers distribute requests using transport-layer information (source/destination IP and port) without inspecting packet contents, performing NAT to forward traffic to upstream servers.

How It Works

A client makes a TCP connection to the load balancer’s virtual IP.
The L4 LB reads the TCP/UDP header fields (source IP, dest IP, ports).
The LB selects a backend server using a scheduling algorithm (round robin, least connections, etc.).
The LB performs Network Address Translation (NAT), rewriting the destination IP/port to the selected server.
The server responds directly to the client (DSR mode) or through the LB.
The LB sees only TCP handshake and layer 4 metadata — it never decrypts or inspects the payload.

Visual Explanation

Key Properties

Operates at the transport layer (TCP/UDP), never inspects payload content
Uses Network Address Translation (NAT) to rewrite packet headers
Lower CPU overhead per packet compared to Layer 7 load balancers
Faster throughput on modern hardware due to simpler processing
Supports any TCP/UDP protocol, not just HTTP

Connections

Contrasts with: Layer 7 Load Balancing — transport vs application layer routing tradeoffs
Related: Horizontal Scaling — L4 LB is the primary enabler of horizontal scaling
Related: Reverse Proxy — both terminate and forward traffic; LB focuses on distribution
Related: Active-Passive Failover — LB can detect server failure and reroute traffic

Edge Cases & Gotchas

L4 LB cannot route based on HTTP headers, cookies, or URL paths — all servers must be interchangeable
Sticky sessions require client IP hashing or a separate session store since the LB cannot read cookies
NAT rewrites break some protocols that embed IP addresses in the payload (FTP, SIP) without protocol-specific helpers

layer7-load-balancing

2026-05-15T00:00:00.000Z

The Problem

Not all requests are equal — some requests need different backend treatment based on their content (e.g., API version, user type, resource type). Layer 4 distribution cannot make these distinctions.

Core Idea

Layer 7 load balancers inspect application-layer content (HTTP headers, cookies, message bodies) to make intelligent routing decisions based on request content rather than just IP and port.

How It Works

The L7 LB terminates the incoming TCP connection from the client.
It reads the full request payload — HTTP method, URI, headers, cookies, body.
It makes a routing decision based on content: route /api/v2/ to server group A, /images/ to dedicated media servers.
It opens a new TCP connection to the selected backend server (or uses a keep-alive pool).
It forwards the request, potentially transforming headers or rewriting paths.
The response flows back through the LB, which may modify headers or compress content.

Visual Explanation

Key Properties

Operates at the application layer (HTTP, gRPC, WebSocket)
Inspects message content for advanced routing decisions
More flexible routing than Layer 4 — path-based, header-based, cookie-based
Higher CPU overhead per request due to content inspection and connection termination
Commonly acts as a reverse proxy (e.g., Nginx, HAProxy, Envoy)

Connections

Contrasts with: Layer 4 Load Balancing — application vs transport layer routing
Related: Reverse Proxy — L7 LB often functions as a reverse proxy with routing logic
Related: Horizontal Scaling — L7 LB enables granular scaling of individual service groups

Edge Cases & Gotchas

TLS termination at the LB means the LB must manage certificates, adding key management complexity
L7 LB is slower than L4 under high load because it terminates connections and inspects payloads
WebSocket connections require special handling — the LB must recognize the upgrade header and switch to tunnel mode

Load Balancer vs Reverse Proxy — Infrastructure Component Comparison

2026-05-15T00:00:00.000Z

What’s Being Compared

Load balancers and reverse proxies are both network intermediaries that sit between clients and servers, but they serve different primary purposes. Load balancers distribute traffic across multiple servers; reverse proxies provide a unified interface to backend services. Understanding when to use which — or both — is essential for system architecture.

The Core Tension

The fundamental distinction is whether you have multiple servers doing the same thing (load balancer territory) or whether you need to abstract, protect, and augment a backend (reverse proxy territory). In practice, tools like Nginx and HAProxy blur this line by supporting both roles.

Comparison

Dimension	Layer 4 Load Balancing / Layer 7 Load Balancing	Reverse Proxy
Primary purpose	Distribute load across multiple servers	Centralize and protect backend services
When needed	Multiple servers serving same function	Even a single server benefits
Traffic distribution	Yes — random, round-robin, least-loaded	Not primary focus
SSL termination	Supported	Supported
Caching	Not primary focus	Supported
Compression	Not primary focus	Supported
Static content serving	No	Yes
Single point of failure	Yes — requires multiple LBs	Yes — requires multiple RPs
Examples	HAProxy (LB mode), AWS ELB	Nginx, HAProxy (reverse proxy mode)

When to Choose Load Balancer

You have multiple application servers that need traffic distributed among them
You need health checks to route away from failing servers
You need session persistence (sticky sessions)
You need to support horizontal scaling of stateless services

When to Choose Reverse Proxy

You have only one application server but want SSL termination, caching, or compression
You want to hide backend server details from clients
You need to serve static content directly without hitting the app server
You want to compress responses before sending to clients

The Insight

Nginx and HAProxy can act as both, and in production they often do. A typical setup: reverse proxy (Nginx) terminates SSL, serves static files, and reverse-proxies API calls to a set of application servers behind a load balancer (HAProxy) that distributes requests. The lines blur because a Layer 7 load balancer IS a reverse proxy by function — it terminates connections, inspects content, and forwards to backends.

Connections

Layer 4 Load Balancing — transport-level LB compared in this analysis
Layer 7 Load Balancing — application-level LB, often same as reverse proxy
Reverse Proxy — the other side of this comparison
Horizontal Scaling — LB enables horizontal scaling
DNS in System Design — DNS can direct traffic to load balancers

master-master-replication

2026-05-15T00:00:00.000Z

The Problem

Master-slave replication has a single write point — if the master fails, the system cannot accept writes until a slave is promoted to master, causing write downtime.

Core Idea

Master-master replication designates two or more database nodes as masters, each accepting both reads and writes. Masters synchronize writes between each other. If one master fails, the other continues serving both reads and writes, eliminating write downtime.

How It Works

Both masters accept read and write operations from clients.
A load balancer distributes write traffic between masters, or application logic decides which master to write to.
Each write is recorded in the node’s binary log and replicated to the other master(s).
Masters coordinate to apply each other’s changes, detecting and resolving conflicting writes.
With two masters, conflicts are rare — with three or more, conflict resolution (last-write-wins, CRDTs, or custom merge logic) becomes necessary.
If one master fails, the other continues handling all traffic.

Visual Explanation

Key Properties

Multi-master writes — any master can accept write operations
Both serve reads and writes — no read-only nodes
Continued operation on single failure — remaining master handles all traffic
Loosely consistent or higher write latency — synchronous replication between masters adds latency; async risks divergence
Conflict resolution complexity — concurrent writes to the same data on different masters must be reconciled

Connections

Contrasts with: Master-Slave Replication — multi-writer vs single-writer with read replicas
Related: Active-Active Failover — similar pattern where both servers handle traffic
Related: Database Federation — an alternative scaling approach that splits data by function
Related: Sharding — each shard can use master-master replication for high write availability
Related: CAP Theorem — master-master typically favors availability and partition tolerance over strong consistency

Edge Cases & Gotchas

Write conflicts — two masters accepting concurrent writes to the same row can produce conflicting values; resolution strategies (LWW, application-merge, CRDT) each have tradeoffs.
Replication loops — a write from Master A replicated to Master B may replicate back to Master A unless the system tracks which origin a change came from.
Higher write latency — synchronous multi-master requires each write to be acknowledged by all masters, increasing p99 write latency significantly.

master-slave-replication

2026-05-15T00:00:00.000Z

The Problem

A single database is a single point of failure — if it goes down, the entire system loses data access. It also creates a read bottleneck: all read queries hit one server, limiting throughput.

Core Idea

Master-slave replication designates one database as the master (handling all writes) and one or more slaves (handling read queries). The master asynchronously replicates writes to slaves. If the master fails, the system runs in read-only mode until a slave is promoted to master.

How It Works

All write operations (INSERT, UPDATE, DELETE) are sent to the master database.
The master records the write in its binary log (binlog).
Slaves connect to the master and pull changes from the binlog.
Slaves replay the changes locally, staying eventually consistent with the master.
Read queries can be routed to any slave to distribute read load.
Slaves can chain — one slave acts as a replication source for other slaves (tree topology).
If the master fails, an operator or automated system promotes a slave to become the new master.

Visual Explanation

Key Properties

Single write master — all writes go through one node, simplifying conflict resolution
Multiple read slaves — read capacity scales linearly with number of slaves
Asynchronous replication — slaves may lag behind the master (eventual consistency)
Read-only on master failure — writes stop until a slave is promoted
Requires promotion logic — automated or manual failover to elect a new master

Connections

Contrasts with: Master-Master Replication — single write point vs multiple write points
Related: Active-Passive Failover — similar pattern where one server is active, another stands by
Related: Strong Consistency — reading from the master guarantees consistency; slaves may serve stale data
Related: Sharding — each shard can use master-slave replication for fault tolerance
Related: SQL Tuning — tuning benefits both master (write performance) and slaves (read performance)

Edge Cases & Gotchas

Replication lag — under heavy write load, slaves can fall seconds or minutes behind, serving stale data to users.
Split-brain on async failover — if the old master comes back after a slave is promoted, two masters may accept writes. Use fencing or STONITH to prevent this.
Not all storage engines support it — MySQL MyISAM does not support replication the same way InnoDB does; check engine compatibility.

message-queues

2026-05-15T00:00:00.000Z

The Problem

Synchronous execution of expensive operations blocks the user and degrades responsiveness. Direct point-to-point integration between services creates tight coupling and makes systems brittle under load spikes.

Core Idea

Message queues receive, hold, and deliver messages asynchronously — a publisher sends a job, a worker picks it up later, and the user is not blocked. This decouples producers from consumers and provides a buffer during traffic spikes.

How It Works

Application (publisher) sends a job message to the queue.
Queue acknowledges receipt immediately.
Application notifies the user of job status (“processing”).
A worker (consumer) picks up the job from the queue.
Worker processes the job and signals completion.

Popular implementations: Redis (simple, high throughput, messages can be lost), RabbitMQ (AMQP, managed delivery guarantees), and SQS (fully hosted, at-least-once delivery, may deliver duplicates).

Visual Explanation

Key Properties

Asynchronous processing — producers never wait for consumers
Decouples producers and consumers (they don’t need to know about each other)
Buffers messages during traffic spikes, preventing producer overload
Worker-based processing enables horizontal scaling of consumers
Different reliability guarantees (at-most-once, at-least-once, exactly-once)

Connections

Related: Task Queues — message queues focus on message delivery; task queues focus on scheduling and executing compute work
Related: Back Pressure — queue growth beyond capacity triggers back pressure mechanisms
Related: Microservices Architecture — queues enable loose coupling between services
Related: Write-Behind Cache — both use async processing patterns to decouple operations

Edge Cases & Gotchas

Message ordering: Most queues do not guarantee strict FIFO ordering under high concurrency. Use a FIFO queue or sequence IDs if order matters.
Duplicate messages: At-least-once delivery guarantees can result in duplicate processing. Workers should be idempotent.
Poison pills: Malformed messages that cause workers to fail repeatedly can block the queue. Implement dead-letter queues to isolate them.

microservices-architecture

2026-05-15T00:00:00.000Z

The Problem

Monolithic applications grow too large for teams to develop, test, deploy, and scale independently. A single codebase creates coordination bottlenecks, long deployment cycles, and forces all parts of the system to use the same technology stack.

Core Idea

Microservices architecture decomposes an application into independently deployable, small, modular services — each running its own process and communicating via lightweight mechanisms (HTTP, RPC, or message queues). Each service is built around a specific business capability and can be developed, deployed, and scaled independently.

How It Works

Analyze the application domain and identify bounded contexts (e.g., user profile, feed, search, payments).
Create a separate service for each bounded context, each with its own codebase and data store.
Define service APIs (REST, gRPC, or GraphQL) for inter-service communication.
Deploy each service as an independent process — typically in containers.
Each team owns one or more services end-to-end: development, testing, deployment, and operations.
Services scale independently — the feed service can have 10 instances while payments runs on 2.

Visual Explanation

Key Properties

Independently deployable — each service can be deployed without coordinating with other teams
Single responsibility — each service owns one business capability
Polyglot technology — services can use different languages, databases, and frameworks
Team autonomy — teams own their services end-to-end
Isolated failure — a crash in one service doesn’t bring down the entire system

Connections

Contrasts with: monolithic architecture — a single deployable unit vs many independent services
Related: Service Discovery — microservices need dynamic discovery to find each other’s network locations
Related: Message Queues — enable asynchronous, reliable communication between services
Related: Horizontal Scaling — each service can be scaled independently based on its own load
Related: RPC — a common communication mechanism between microservices

Edge Cases & Gotchas

Distributed monolith anti-pattern — services that are tightly coupled via shared databases or chatty APIs defeat the purpose of microservices.
Operational complexity — deploying 10 services is harder than deploying 1; requires container orchestration (Kubernetes), service mesh, and observability tooling.
Data consistency — transactions spanning multiple services require sagas or eventual consistency; no cross-service ACID.

nosql-database-types

2026-05-15T00:00:00.000Z

The Problem

Relational databases (RDBMS) enforce rigid schemas, require ACID transactions, and struggle with semi-structured data, massive scale, and flexible schemas. Many modern applications need faster writes, horizontal scalability, or specialized data models that SQL databases do not provide efficiently.

Core Idea

NoSQL databases are categorized into four main types based on their data model: key-value stores (hash table), document stores (JSON/XML), wide column stores (nested maps of rows and columns), and graph databases (nodes and edges). Each type trades ACID guarantees for performance, scalability, or flexibility in a specific access pattern.

How It Works

Key-value stores (Redis, Memcached, DynamoDB): data is stored as opaque blobs keyed by a unique identifier. O(1) reads/writes, in-memory or SSD-backed. Best for caching, session storage, and leaderboards.
Document stores (MongoDB, CouchDB): data is stored as self-describing documents (JSON, BSON, XML). Documents can have nested structures and varying schemas. Best for catalogs, content management, and event logging.
Wide column stores (BigTable, HBase, Cassandra): data is organized as ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>. Rows can have different columns. Best for time-series data, IoT, and analytics.
Graph databases (Neo4j, Amazon Neptune): data is stored as nodes (entities) and edges (relationships) with properties on both. Best for social graphs, recommendation engines, and fraud detection.

Visual Explanation

digraph NoSQLTypes {
    rankdir=TB;
    node [shape=box, style=rounded];
 
    NoSQL [label="NoSQL Databases"];
 
    KV [label="Key-Value Store\nRedis, Memcached\nO(1) lookups"];
    Doc [label="Document Store\nMongoDB, CouchDB\nJSON documents"];
    Wide [label="Wide Column Store\nCassandra, HBase\nColumn families"];
    Graph [label="Graph Database\nNeo4j, Neptune\nNodes + Edges"];
 
    UseKV [label="Caching\nSessions\nLeaderboards"];
    UseDoc [label="Catalogs\nCMS\nEvent logs"];
    UseWide [label="Time series\nIoT\nAnalytics"];
    UseGraph [label="Social graphs\nRecommendations\nFraud"];
 
    NoSQL -> KV;
    NoSQL -> Doc;
    NoSQL -> Wide;
    NoSQL -> Graph;
 
    KV -> UseKV;
    Doc -> UseDoc;
    Wide -> UseWide;
    Graph -> UseGraph;
}

Key Properties

BASE semantics — Basically Available, Soft state, Eventual consistency (instead of ACID)
Denormalized by nature — data is stored in read-optimized shapes; joins happen in application code
No true ACID transactions — most NoSQL databases do not support multi-document/row transactions
Designed for horizontal scaling — built-in sharding and replication for massive scale
Each type optimized for specific access patterns — choosing the wrong type leads to poor performance

Connections

Builds into: SQL vs NoSQL — a synthesis comparing relational and non-relational approaches
Related: CAP Theorem — NoSQL databases typically prioritize Availability and Partition tolerance over Consistency
Related: Denormalization — NoSQL databases are inherently denormalized; data duplication is by design
Related: Sharding — most NoSQL databases have built-in sharding, making horizontal scaling straightforward
Related: Cache-Aside — key-value stores (Redis, Memcached) are the most common caching layer

Edge Cases & Gotchas

Wrong tool for the job — using a document store for deeply relational data (e.g., accounting systems) leads to application-level join spaghetti and data inconsistency.
NoSQL does not mean no schema — while schemas are flexible at write time, the application code implicitly defines a schema that must be managed; schema drift is a real problem.
Eventual consistency surprises — reading your own write may return stale data; this breaks user expectations in applications like social media or e-commerce.

performance-vs-scalability

2026-05-15T00:00:00.000Z

The Problem

Engineers often use “performance” and “scalability” interchangeably, leading to incorrect architectural decisions. A system that performs well for a single user may collapse under load, while a scalable system may be individually slow.

Core Idea

Performance measures how fast a system handles a single unit of work (response time for one request). Scalability measures how well the system maintains that performance as load increases (throughput with added resources). A system can be performant but not scalable, or scalable but not performant.

How It Works

Measure baseline: Determine response time for a single request under minimal load (performance baseline).
Increase load: Gradually ramp up concurrent requests while monitoring response time.
Identify knee point: Observe where response time degrades significantly — the system is no longer scaling.
Add resources: Increase nodes, memory, or connections. If response time returns to baseline, the system scales horizontally.
Re-evaluate: Continue adding load until the next knee point. Diminishing returns indicate scaling limits.

Visual Explanation

Key Properties

Performance = speed measured for a single user or request (latency and throughput)
Scalability = ability to maintain performance proportionally as resources are added
Linear scalability means doubling resources doubles capacity with no performance loss
Not interchangeable: a Ferrari is performant (fast for one), a bus fleet is scalable (many passengers), a bus is neither

Connections

Related: Latency vs Throughput — both are dimensions of performance
Builds into: Horizontal Scaling — adding resources to improve scalability
Related: CAP Theorem — system design trade-offs affect both performance and scalability
Related: Back-of-Envelope Estimates — quantifying performance expectations

Edge Cases & Gotchas

Superlinear scaling: Some systems scale better than linearly (e.g., caching clusters where more nodes reduce cache contention). This is rare and often transient.
Performance hides poor scalability: A fast single node can mask the need to scale until load spikes reveal the bottleneck.
Amdahl’s Law applies: The serial portion of any workload caps maximum speedup, no matter how many resources are added.

refresh-ahead-cache

2026-05-15T00:00:00.000Z

The Problem

Cache entries expire at TTL boundaries, causing latency spikes as data must be re-fetched from the database. These spikes degrade user experience for popular entries.

Core Idea

Refresh-ahead proactively refreshes recently accessed cache entries before they expire. By predicting which entries will be needed next, it reduces latency while keeping hot data fresh, at the cost of potentially wasting resources on incorrectly predicted entries.

How It Works

Track recently accessed cache entries and their access frequency.
Before an entry’s TTL expires, predict whether it will be accessed again.
If predicted to be needed, proactively re-fetch the data from the database.
Update the cache entry with fresh data and a new TTL, transparent to the application.
Result: the application almost never encounters a cold miss for popular data.

Incorrect predictions hurt performance by wasting I/O on entries that will never be accessed again.

Visual Explanation

Key Properties

Proactive refresh before TTL expiry reduces access latency
Requires accurate prediction heuristics to avoid wasted refreshes
Can hurt performance if predictions are wrong (wasted I/O, cache churn)
Works well with predictable, recurring access patterns
Transparent to the application — no code changes needed on the read path

Connections

Contrasts with: Cache-Aside — proactive vs reactive caching
Related: Write-Through Cache — both proactively keep cache fresh
Related: Pull CDN — CDN pull is reactive; refresh-ahead is proactive
Related: Eventual Consistency — refresh-ahead minimizes the window of inconsistency by keeping hot entries fresh

Edge Cases & Gotchas

Wasted refreshes: Predictions for entries that are never accessed again waste CPU and database I/O. This can degrade overall system throughput if prediction accuracy is low.
Cold start: Refresh-ahead has no access history for new entries, so it cannot predict them — they will still experience a cold miss on first access.
Oscillation risk: If prediction logic is too aggressive, the cache may constantly refresh entries, reducing effective TTL and increasing database load without benefit.

rest-architectural-style

2026-05-15T00:00:00.000Z

The Problem

Tight coupling between client and server (as in RPC) makes API evolution difficult, prevents independent deployment, and complicates horizontal scaling.

Core Idea

REST is an architectural style that enforces a client/server model where clients interact with resources through a uniform interface — URIs identify resources, HTTP verbs define actions, status codes communicate results, and HATEOAS links enable navigation. Each request is stateless and self-contained.

How It Works

Resources are identified by URIs (e.g., /users/42).
Clients manipulate resources using standard HTTP verbs: GET (read), POST (create), PUT (replace), PATCH (partial update), DELETE (remove).
Errors are self-descriptive via HTTP status codes (200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error).
HATEOAS (Hypermedia As The Engine Of Application State): responses include links to navigate related resources.
Each request is stateless — the server does not store client session context between requests.
Responses are cacheable via HTTP cache headers (Cache-Control, ETag).

Visual Explanation

Key Properties

URI-based resource identification — everything is a resource (noun)
HTTP verb-based actions define the uniform interface
Stateless — each request contains all context needed to process it
Cacheable responses reduce server load and improve latency
Uniform interface minimizes client-server coupling

Connections

Contrasts with: RPC — REST exposes data/resources (nouns); RPC exposes behaviors (verbs)
Related: Microservices Architecture — REST APIs are a primary communication mechanism between services
Related: Cache-Aside — REST supports caching via HTTP cache headers (Cache-Control, ETag)
Related: Layer 7 Load Balancing — L7 load balancers can inspect and route RESTful requests based on URI paths and HTTP methods

Edge Cases & Gotchas

Over-fetching / under-fetching: REST responses return fixed resource representations, which may include unnecessary fields (over-fetching) or miss needed data (under-fetching). GraphQL or sparse fieldsets address this.
No standard for partial updates: PUT replaces the entire resource; PATCH semantics vary. Clients must understand which verb and representation to use.
Statelessness shifts complexity: Session state must be stored client-side or in an external store (e.g., Redis), pushing complexity out of the server.

reverse-proxy-pattern

2026-05-15T00:00:00.000Z

The Problem

Backend servers should not be directly exposed to the internet for security and scalability reasons. Clients should not have to know about internal server topology, and managing SSL certificates, caching, and compression at every backend is wasteful.

Core Idea

A reverse proxy centralizes internal services and provides a unified public interface. It forwards incoming client requests to the appropriate backend server and returns the response, acting as a single gatekeeper that handles cross-cutting concerns like SSL termination, caching, compression, and static content serving.

How It Works

Client sends a request to the reverse proxy’s public address (e.g., https://api.example.com).
Reverse proxy terminates the TLS connection (SSL termination), decrypting the request.
Proxy checks its cache — if a fresh response exists, returns it immediately.
If not cached, proxy forwards the request to the appropriate backend server based on URL path or host header.
Backend processes the request and returns the response to the proxy.
Proxy can compress the response (gzip), cache it, and add security headers before returning to the client.

Visual Explanation

Key Properties

Single public-facing endpoint — all traffic arrives at one address
Hides backend topology — internal server layout is never exposed to clients
SSL termination — offloads certificate management and decryption from backends
Response caching — serves repeated requests without contacting backends
Response compression — reduces bandwidth for text-based responses

Connections

Built from: Load Balancer — reverse proxy often incorporates load balancing logic
Contrasts with: Layer 4 Load Balancing — L4 LB distributes traffic at transport layer without inspecting content; RP operates at application layer
Related: Layer 7 Load Balancing — tools like Nginx and HAProxy support both reverse proxy and L7 load balancing
Related: Push CDN — both cache and serve static content; CDN is geographically distributed while RP is centralized
Related: DNS in System Design — DNS resolves the domain name to the reverse proxy’s IP address

Edge Cases & Gotchas

Single point of failure — if the reverse proxy goes down, the entire service is unreachable; always deploy at least two in an active-passive or active-active configuration.
Request buffering — large uploads can exhaust proxy memory; configure request size limits or stream directly to backends.
Latency overhead — every request passes through an extra hop; this is negligible in most cases but matters for ultra-low-latency systems.

rpc-remote-procedure-call

2026-05-15T00:00:00.000Z

The Problem

Network communication between services requires manual serialization, addressing, protocol handling, and error management — this is complex, error-prone, and obscures business logic.

Core Idea

RPC makes a remote procedure call look indistinguishable from a local call. The client calls a local stub that marshals the function name and arguments into a network message, sends it to the server, which unmarshals and executes the function, and returns the result — all transparent to the application code.

How It Works

Client calls a local stub function as if it were a local procedure.
The client stub marshals the procedure ID and arguments into a binary or structured message.
The client OS sends the message over the network to the server.
The server OS passes the message to the server stub.
The server stub unmarshals the message, locates and calls the actual procedure.
The procedure executes and returns a result to the server stub.
The response follows the reverse path back to the client.

Popular RPC frameworks include Protocol Buffers (gRPC), Apache Thrift, and Apache Avro.

Visual Explanation

Key Properties

Hides network complexity behind a familiar local-call abstraction
Request-response protocol — synchronous by default
Automatically marshals/unmarshals parameters and return values
Tight client-server coupling (interface contract is shared)
Better suited for internal service-to-service communication than public APIs

Connections

Contrasts with: REST — RPC exposes behaviors (functions); REST exposes resources (nouns)
Related: Microservices Architecture — RPC is a common inter-service communication pattern
Related: Service Discovery — RPC clients need to locate server instances dynamically
Related: Message Queues — RPC is synchronous; message queues enable async communication

Edge Cases & Gotchas

Network failures are invisible: The local-call abstraction hides network partitions, timeouts, and partial failures. RPC calls can fail silently or hang.
Versioning hell: Evolving the interface contract requires coordinated deployment of both client and server. Use schema evolution features (e.g., Protobuf field tags) to mitigate.
Performance overhead: Marshaling, network round-trips, and connection management add latency compared to in-process calls. Batch calls or use streaming for high-throughput scenarios.

service-discovery

2026-05-15T00:00:00.000Z

The Problem

In dynamic microservice environments, IP addresses and ports change frequently as instances are created, destroyed, or moved during scaling events and failures. Hard-coding addresses makes the system brittle and unmanageable.

Core Idea

Service discovery tools (Consul, Etcd, Zookeeper) maintain a registry of service names mapped to their current network locations (IP + port). Services register themselves on startup and the registry performs health checks to remove unhealthy instances, allowing clients to always find live services.

How It Works

On startup, each service instance registers its name, IP address, and port with the discovery service.
The discovery service runs periodic health checks (e.g., HTTP /health endpoint) against registered instances.
Unhealthy instances that fail health checks are automatically deregistered.
When a service (or API gateway) needs to call another service, it queries the registry for the service name.
The registry returns the list of healthy instances, and the client picks one (round-robin, random, or least-loaded).
The key-value store in the registry can hold shared configuration values (feature flags, DB URLs).

Visual Explanation

Key Properties

Dynamic registration/deregistration — instances automatically register on startup and deregister on shutdown
Health checks — continuous verification that instances are alive and ready
Key-value store — shared configuration storage alongside the registry
Consistent naming — services are found by logical name, not physical address

Connections

Built from: Microservices Architecture — dynamic microservice environments create the need for discovery
Related: Layer 7 Load Balancing — L7 load balancers use the service registry to discover healthy backends
Related: Horizontal Scaling — scaling up/down changes instance counts, and discovery tracks the current set
Related: Message Queues — an alternative async communication pattern that decouples services without direct discovery
Related: Reverse Proxy Pattern — reverse proxy can use service discovery to route to backends

Edge Cases & Gotchas

Cached stale entries — if a service crashes without deregistering, the registry may return a dead instance until the next health check.
Thundering herd on registry — if every client aggressively re-queries on failure, the registry can be overwhelmed; client-side caching with TTL is essential.
Consistency vs. availability tradeoff — highly available registries (eventually consistent) may return stale data; strongly consistent registries (Paxos/Raft based) add write latency.

sharding

2026-05-15T00:00:00.000Z

The Problem

As data grows, a single database becomes too slow — indexes grow too large to fit in memory, write throughput plateaus, and backup/recovery times become dangerously long.

Core Idea

Sharding distributes data across multiple databases such that each database (shard) manages a subset of the data, reducing per-shard read/write traffic, shrinking index sizes, and allowing the system to scale horizontally by adding more shards.

How It Works

Choose a shard key — an attribute that determines data placement (e.g., user ID, geographic region, last name initial).
Define a sharding strategy: range-based (A–M on shard 1, N–Z on shard 2), hash-based (hash(user_id) % N), or directory-based (lookup table).
Each shard is an independent database with its own subset of data.
Queries include the shard key so the application or proxy routes them to the correct shard.
Add more shards as data grows — consistent hashing minimizes data movement during rebalancing.

Visual Explanation

Key Properties

Data distributed by key — each shard holds a non-overlapping subset
Less traffic per shard — read/write load is divided by the number of shards
Smaller indexes — each shard’s index fits in memory, speeding queries
Failure isolation — a failure in one shard doesn’t affect other shards
No single write serialization point — multiple shards accept writes in parallel

Connections

Related: Database Federation — federation splits by function, sharding splits by key (complementary strategies)
Related: Denormalization — reduces need for cross-shard joins by duplicating data
Related: Horizontal Scaling — sharding is the database equivalent of horizontal scaling
Related: Master-Slave Replication — each shard can have its own replication topology for fault tolerance
Related: Consistent Hashing — a key algorithm for minimizing data movement when adding/removing shards

Edge Cases & Gotchas

Resharding complexity — adding a new shard with a naive hash(N) strategy requires reshuffling most data; consistent hashing reduces but doesn’t eliminate this.
Skewed shards — if the shard key is poorly chosen, one shard may get 80% of traffic while others sit idle.
Cross-shard queries — operations that span multiple shards require scatter-gather (query all shards and merge results), which is slow and complex.

sql-tuning

2026-05-15T00:00:00.000Z

The Problem

Poorly written SQL queries can be 100–1000x slower than optimized alternatives. Without benchmarking and profiling, development teams deploy queries that waste database CPU, memory, and I/O — degrading system performance for all users.

Core Idea

SQL tuning is the practice of optimizing schema design, indexing, and query structure to improve database performance. The process follows: benchmark (establish baseline), profile (identify slow queries with tools like the slow query log), and optimize (tighten schema, add indexes, rewrite queries).

How It Works

Benchmark — use tools like ab or sysbench to establish baseline query performance.
Profile — enable the slow query log to identify queries that exceed a threshold (e.g., 100ms).
Tighten schema — use CHAR instead of VARCHAR for fixed-length fields, INT for numbers, DECIMAL for currency, TEXT for large blobs, and add NOT NULL where possible to improve search performance.
Add indexes — index columns used in WHERE, ORDER BY, GROUP BY, and JOIN clauses; use B-tree indexes for sorted access.
Avoid expensive joins — denormalize hot paths; partition very large tables; use query cache for repeated reads.
Monitor — continuously profile to catch regressions after schema or code changes.

Visual Explanation

Key Properties

Benchmark then profile — always measure before optimizing; don’t guess at bottlenecks
Index WHERE/GROUP BY/ORDER BY/JOIN columns — these are the primary targets for index optimization
CHAR is faster than VARCHAR — fixed-width fields avoid length-prefix overhead; use for codes, enums, fixed identifiers
NOT NULL improves search performance — nullable columns require extra checks per row
Index updates slow writes — each index must be updated on INSERT/UPDATE; balance read vs write needs

Connections

Related: Denormalization — a specific SQL tuning technique that trades write speed for read speed
Related: Master-Slave Replication — tuning benefits both masters (write-heavy) and slaves (read-heavy) differently
Related: NoSQL Database Types — some tuning concerns (schema design, joins) are avoided by moving to NoSQL
Related: Cache-Aside — caching reduces database load, complementing SQL tuning efforts
Related: Sharding — sharding reduces per-node data volume, which directly improves query performance

Edge Cases & Gotchas

Premature optimization — tuning queries that run once a day for 200ms is a waste of effort; profile first to find the real bottlenecks.
Index overkill — too many indexes slow down writes significantly and increase disk usage; a table with 10 indexes on 1M rows can see 3x slower inserts.
Query cache invalidation — MySQL query cache is invalidated on every write to the table; on write-heavy tables, the cache does more harm than good.

SQL vs NoSQL — Database Paradigm Comparison

2026-05-15T00:00:00.000Z

What’s Being Compared

SQL (relational) and NoSQL (non-relational) databases represent fundamentally different approaches to data storage. SQL databases enforce rigid schemas and support ACID transactions; NoSQL databases offer flexible schemas and horizontal scalability at the cost of consistency guarantees. The choice is not about which is better — it’s about which fits the data and access patterns.

The Core Tension

SQL optimizes for data integrity and complex relationships through normalization, joins, and transactions. NoSQL optimizes for scale and flexibility through denormalization, horizontal partitioning, and relaxed consistency. You trade relational power for operational simplicity at scale.

Comparison

Dimension	SQL (RDBMS)	NoSQL
Data structure	Tables with rows and columns	Key-value, documents, wide columns, graphs
Schema	Strict, predefined	Dynamic, flexible
Relationships	Foreign keys + JOINs	Embedded documents or app-level joins
Transactions	ACID (Atomic, Consistent, Isolated, Durable)	BASE (Basically Available, Soft state, Eventual consistency)
Scaling	Vertical primarily (with replication/sharding)	Horizontal by design
Consistency	Strong consistency	Eventual consistency typical
Best for	Structured data, complex queries, transactions	Semi-structured data, massive scale, flexible schema
Examples	MySQL, PostgreSQL, Oracle	MongoDB, Cassandra, Redis, Neo4j

When to Choose SQL

Data is highly structured with clear relationships
You need complex JOINs and multi-row transactions
Your workload has more reads than writes (typical 100:1 or 1000:1)
You need strong consistency guarantees
Your team is familiar with relational modeling

When to Choose NoSQL

Data is semi-structured or unstructured
You need to store terabytes or petabytes of data
Your schema changes frequently
You need very high write throughput
You’re handling clickstreams, logs, leaderboards, or temporary data (shopping carts)

The Insight

Many production systems use both (polyglot persistence). The relational database holds core business entities with transactional integrity, while NoSQL stores handle high-volume, flexible data like clickstream logs, session data, and user feeds. The question isn’t which one, but which one for which part of the system.

Connections

NoSQL Database Types — the four categories of NoSQL databases
CAP Theorem — explains the consistency trade-offs in NoSQL
Sharding — horizontal scaling technique used by NoSQL
Denormalization — SQL technique that mirrors NoSQL’s approach
Master-Slave Replication — SQL scaling technique

strong-consistency

2026-05-15T00:00:00.000Z

The Problem

Many applications — banking, inventory management, distributed locking — cannot tolerate reading stale data. A user who transfers money should see the updated balance on refresh.

Core Idea

Strong consistency guarantees that after a write completes, all subsequent reads (from any node) will return that write’s value. This is achieved through synchronous replication: a write is not acknowledged to the client until a quorum of nodes confirms they have persisted it. The system behaves as if there is a single copy of the data, regardless of replication factor.

How It Works

Client issues write: The write request is sent to a coordinator node.
Synchronous replication: The coordinator sends the write to all replicas and waits for acknowledgment from a quorum (e.g., majority).
Acknowledge to client: Once the quorum acknowledges, the client receives confirmation. All future reads, regardless of which node they hit, will see this value.
Read follows same path: Reads may also require quorum to ensure they see the latest value, or they may go through the primary node (which always has the latest write).

Visual Explanation

Key Properties

All reads see the latest write — behaves like a single-node system
Synchronous replication — writes are committed to a quorum before acknowledgment
Higher latency than weak or eventual consistency (waiting for slowest quorum member)
Used in RDBMS (primary reads), ZooKeeper (atomic broadcast), and file systems (NFS, GFS metadata)

Connections

Contrasts with: Eventual Consistency — sync vs async replication, immediate guarantees vs eventual convergence
Contrasts with: Weak Consistency — deterministic guarantees vs no guarantees at all
Related: CP — Consistency and Partition Tolerance — CP systems guarantee strong consistency during normal operation
Related: Master-Slave Replication — reading from the master provides strong consistency; slaves may lag

Edge Cases & Gotchas

Performance cliff under contention: Strong consistency requires global ordering of writes. Under high contention, this serialization becomes a bottleneck and throughput collapses.
Not truly linearizable in practice: Many systems advertise strong consistency but use clock-based ordering, which can fail under clock skew. True linearizability (e.g., Spanner’s TrueTime) is rare and expensive.
Multi-region cost: Synchronous replication across geographic regions is extremely slow (speed of light latency). Global strong consistency is impractical for most systems — multi-master or eventual consistency is preferred.

task-queues

2026-05-15T00:00:00.000Z

The Problem

Computationally intensive or time-based background jobs (image processing, report generation, batch operations) need scheduling, execution management, and result delivery that message queues alone do not provide.

Core Idea

Task queues receive tasks with their related data, schedule and execute them on worker processes, and deliver results back to the caller. They extend message queue concepts with scheduling, retries, and result tracking for compute-heavy workloads.

How It Works

Client submits a task (function + parameters) to the queue.
Queue schedules the task for execution (immediately or at a future time).
A worker picks up the task and executes the computation.
Worker stores the result or delivers it back to the client.
If the task fails, the queue can retry according to configured policies.

Celery (Python) is a popular task queue framework with support for periodic scheduling, result backends, and multiple message broker backends (Redis, RabbitMQ).

Visual Explanation

Key Properties

Schedules and executes computational tasks (not just message passing)
Supports scheduled/delayed execution (cron-like scheduling)
Returns results to the caller via a result backend
Built-in retry and error handling for failed tasks
Well-suited for CPU-intensive or long-running background work

Connections

Related: Message Queues — task queues extend message queue concepts with scheduling and result tracking
Related: Back Pressure — prevents task queue overflow under heavy submission
Related: Microservices Architecture — background processing offloads work from request path
Contrasts with: synchronous processing — async background computation vs inline blocking execution

Edge Cases & Gotchas

Task idempotency: Retries can cause duplicate execution. Design tasks to be idempotent or use a deduplication mechanism.
Worker death: If a worker dies mid-task, the task is lost or stuck. Use task acknowledgements and visibility timeouts to re-queue.
Task starvation: Long-running tasks can block workers from picking up short tasks. Use separate queues or priority queues to mitigate.

weak-consistency

2026-05-15T00:00:00.000Z

The Problem

Strong consistency has performance costs that some real-time applications cannot afford. Applications like VoIP, video chat, and multiplayer games need minimal latency above all else.

Core Idea

After a write, subsequent reads may or may not see it — there is no guarantee whatsoever. Weak consistency is a best-effort approach that prioritizes low latency over any read-after-write guarantee. Unlike eventual consistency, there is no promise that replicas will ever converge to the same state.

How It Works

Client writes: The write is accepted by the nearest or fastest-responding node.
Best-effort propagation: The write is broadcast to other nodes with no acknowledgment or ordering guarantees.
Reads return local state: Each read returns whatever the responding node has locally — potentially stale, potentially newer, potentially conflicting.
No convergence contract: Unlike eventual consistency, there is no guarantee that all nodes will eventually hold the same value. If propagation is interrupted, divergence persists.

Visual Explanation

Key Properties

No guarantee that a write will ever be visible to a subsequent read
Lowest latency of any consistency model — no coordination overhead
Best-effort approach — propagation happens but is not enforced
Common in VoIP, video chat, realtime multiplayer games where timing matters more than data accuracy

Connections

Contrasts with: Strong Consistency — weak gives no guarantees, strong guarantees the latest write is always visible
Contrasts with: Eventual Consistency — weak may never converge, eventual guarantees convergence given enough time
Related: AP — Availability and Partition Tolerance — weak consistency prioritizes availability above all
Related: Cache-Aside — cache-aside exhibits weak consistency between cache and database by design

Edge Cases & Gotchas

Write loss: If a node accepts a write and crashes before propagating it, that write may be lost entirely.
Not a good default: Weak consistency is a deliberate trade-off for extreme performance requirements. Using it accidentally (e.g., misconfigured replication) leads to data loss and hard-to-debug heisenbugs.
Hard to test: Since behavior is non-deterministic, weak consistency bugs are notoriously difficult to reproduce in test environments.

write-behind-cache

2026-05-15T00:00:00.000Z

The Problem

Synchronous writes (write-through) add database write latency to every write operation, reducing throughput for write-heavy workloads.

Core Idea

Write-behind (write-back) cache acknowledges the write to the application immediately and asynchronously persists the data to the database. This decouples write latency from database performance, dramatically improving throughput at the cost of potential data loss if the cache fails before the DB write completes.

How It Works

Application adds or updates an entry in the cache.
Cache immediately acknowledges success to the application.
Cache asynchronously batches and writes data to the database in the background.
The cache may coalesce multiple updates to the same key into a single DB write.

Write performance is greatly improved, but the window between cache acknowledgement and DB persistence creates a risk of data loss.

Visual Explanation

Key Properties

Asynchronous writes decouple application latency from database performance
Risk of data loss if the cache fails before the DB write completes
More complex to implement than write-through (needs durability guarantees)
Ideal for write-heavy workloads that can tolerate temporary inconsistency
Can batch and coalesce writes for better DB efficiency

Connections

Contrasts with: Cache-Aside — app initiates vs cache initiates DB write
Contrasts with: Write-Through Cache — async vs sync DB write
Related: Message Queues — similar async processing and buffering pattern
Related: Eventual Consistency — write-behind creates a window of temporary inconsistency

Edge Cases & Gotchas

Data loss on cache failure: If the cache node crashes before flushing writes to the database, unpersisted data is lost. Requires replication or persistent caching layers to mitigate.
Inconsistency window: Readers may see data in the cache that hasn’t yet been written to the database. Downstream systems querying the DB directly will not see the update.
Write ordering: If the cache reorders or coalesces writes, the database may receive updates in a different order than the application issued them.

write-through-cache

2026-05-15T00:00:00.000Z

The Problem

Cache-aside can return stale data when the database is updated directly, bypassing the cache. Applications must manually invalidate or update cached entries after DB writes.

Core Idea

Write-through cache treats the cache as the authoritative data store for writes — every write goes to the cache first, then the cache synchronously writes to the database. This ensures the cache always has the latest data at the cost of slower write operations.

How It Works

Application writes or updates an entry in the cache.
The cache synchronously writes the data to the database.
Only after both writes complete does the cache return success.
Reads of recently written data are fast (served from cache).
Cache always has the latest data — no staleness window.

This pattern is often combined with cache-aside for reads on new cache nodes that haven’t been populated yet.

Visual Explanation

Key Properties

Cache writes are synchronous — the database write completes before returning
Data in the cache is never stale (for entries updated through the cache)
Write operations are slower than cache-aside (two sequential writes)
Reads of recently written data are fast (always a cache hit)
Often combined with cache-aside for populating new cache nodes

Connections

Contrasts with: Cache-Aside — app manages cache vs cache manages DB writes
Contrasts with: Write-Behind Cache — sync vs async DB write
Related: Refresh-Ahead Cache — both keep cache fresh but with different triggers
Related: Strong Consistency — write-through ensures cache is consistent with the database

Edge Cases & Gotchas

Write amplification: Every write hits both cache and DB, doubling write operations compared to a direct DB write.
No stale-data protection for direct DB writes: If another process writes directly to the database (bypassing the cache), the cache still becomes stale.
Higher write latency: The client blocks until both cache and DB acknowledge, making writes slower than write-behind or cache-aside.

/wiki / system-design

System Design — Map of Content

Core Concepts

Mechanisms & How Things Work

Comparisons & Tradeoffs

Suggested Reading Order

active-active-failover

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

active-passive-failover

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

ap-availability-partition-tolerance

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

availability-nines

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

availability-parallel-vs-sequence

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

back-of-envelope-estimates

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

back-pressure

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

cache-aside

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

cap-theorem

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

cdn-pull

The Problem