{
  "meta": {
    "title": "napkin.l3.ai — 2026 System Design & Hardware Reality Observatory",
    "subtitle": "Revisit system-design defaults using dated hardware specifications, scoped measurements, and worked estimates with explicit assumptions.",
    "cutoffDate": "2026-10-23"
  },
  "hardwareShifts": [
    {
      "id": "nvme-iops",
      "layer": "Storage Random Read IOPS",
      "metricLabel": "Random Read IOPS (4 KiB)",
      "legacy2016": "Illustrative baseline: 0.09 M IOPS (not a historical market maximum)",
      "modern2026": "6.8M IOPS (Samsung PM1763 PCIe Gen6) / 20.7M (Azure Laosv5)",
      "multiplier": 75.6,
      "multiplierLabel": "75.6× vs assumed baseline",
      "legacyVal": 0.09,
      "modernVal": 6.8,
      "unit": "M IOPS",
      "sourceRef": "S03, S16",
      "designImplication": "Advertised device IOPS require suitable I/O sizes and concurrency; they do not establish database throughput."
    },
    {
      "id": "nvme-bw",
      "layer": "Sequential NVMe Bandwidth",
      "metricLabel": "Sequential Read / Write (GB/s)",
      "legacy2016": "Illustrative baseline: 0.55 GB/s (not a historical market maximum)",
      "modern2026": "28.4 GB/s Read / 21.0 GB/s Write (PCIe Gen6 PM1763)",
      "multiplier": 51.6,
      "multiplierLabel": "51.6× vs assumed baseline",
      "legacyVal": 0.55,
      "modernVal": 28.4,
      "unit": "GB/s",
      "sourceRef": "S03, S05",
      "designImplication": "Sequential bandwidth is a ceiling for a specific access pattern, not a transaction-rate benchmark."
    },
    {
      "id": "host-net",
      "layer": "Instance Network Bandwidth",
      "metricLabel": "Line Rate per Instance (Gbps)",
      "legacy2016": "Illustrative baseline: 10 Gbps (not a historical market maximum)",
      "modern2026": "600 Gbps (AWS C8in) / 800 Gbps (ConnectX-8 NIC)",
      "multiplier": 60,
      "multiplierLabel": "60.0× vs assumed baseline",
      "legacyVal": 10,
      "modernVal": 600,
      "unit": "Gbps",
      "sourceRef": "S08, S11",
      "designImplication": "At ideal line rate, 10 decimal TB takes 133.3 s at 600 Gbps or 8,000 s at 10 Gbps. Storage and protocol overhead increase rebuild time."
    },
    {
      "id": "node-ram",
      "layer": "Scale-Up Memory Ceiling",
      "metricLabel": "Single-instance RAM (TiB)",
      "legacy2016": "Illustrative baseline: 244 GiB = 0.23828125 TiB",
      "modern2026": "32 TiB AWS U7inh; Google separately publishes X5 with 49,152 GB",
      "multiplier": 134.3,
      "multiplierLabel": "134.3× vs assumed baseline",
      "legacyVal": 0.23828125,
      "modernVal": 32,
      "unit": "TiB",
      "sourceRef": "S13, S21",
      "designImplication": "A larger memory ceiling can postpone capacity sharding; workload, availability, and price still determine the design."
    },
    {
      "id": "mem-bw",
      "layer": "Socket Memory Bandwidth",
      "metricLabel": "Peak Socket Memory Bus (GB/s)",
      "legacy2016": "Illustrative baseline: 68 GB/s (not a historical market maximum)",
      "modern2026": "1,638 GB/s (16-ch MRDIMM 12,800 MT/s EPYC 9006)",
      "multiplier": 24.1,
      "multiplierLabel": "24.1× vs assumed baseline",
      "legacyVal": 68,
      "modernVal": 1638.4,
      "unit": "GB/s",
      "sourceRef": "S01, S02",
      "designImplication": "16 channels × 12,800 MT/s × 8 bytes = 1,638.4 GB/s theoretical interface bandwidth; application bandwidth is lower and workload dependent."
    },
    {
      "id": "cpu-cores",
      "layer": "Instance vCPU Capacity",
      "metricLabel": "vCPU count",
      "legacy2016": "Illustrative baseline: 20 vCPU (not a historical market maximum)",
      "modern2026": "192 vCPU (AWS m9g.48xlarge)",
      "multiplier": 9.6,
      "multiplierLabel": "9.6× vs assumed baseline",
      "legacyVal": 20,
      "modernVal": 192,
      "unit": "vCPU",
      "sourceRef": "S10",
      "designImplication": "Assuming 50 µs CPU/request, 1M requests/s uses 50 CPU-seconds/s, or 26% of 192 vCPUs before overhead. This is arithmetic, not a benchmark."
    },
    {
      "id": "ssd-capacity",
      "layer": "Single-Drive SSD Capacity",
      "metricLabel": "Single-drive capacity (decimal TB)",
      "legacy2016": "Illustrative baseline: 3.2 TB (not a historical market maximum)",
      "modern2026": "245.76 TB usable (Micron 6600 ION QLC)",
      "multiplier": 76.8,
      "multiplierLabel": "76.8× vs assumed baseline",
      "legacyVal": 3.2,
      "modernVal": 245.76,
      "unit": "TB",
      "sourceRef": "S06",
      "designImplication": "Capacity is not IOPS, endurance, or durability. Compare individual drive models and failure/rebuild requirements."
    }
  ],
  "latencyLadder": [
    {
      "id": "local-dram",
      "operation": "Random DRAM read (64 B)",
      "category": "local-mem",
      "latencyUs": 0.02,
      "maxQd1Ops": 50000000,
      "transferTaxPerGbUsd": 0,
      "scopeNote": "S32 rounded 20 ns memory reference; not a PostgreSQL buffer hit benchmark. Different operations and environments are not directly comparable.",
      "sourceRef": "S32",
      "statistic": "Rounded reference"
    },
    {
      "id": "same-az-srd",
      "operation": "Same-AZ Network RTT (c8gn ENA Express)",
      "category": "same-az",
      "latencyUs": 52.2,
      "maxQd1Ops": 19157,
      "transferTaxPerGbUsd": 0,
      "scopeNote": "Measured sockperf --full-rtt p50 52.2 µs, p99 56.7 µs, p99.9 59.5 µs (May 2026).",
      "sourceRef": "S30, S34",
      "statistic": "Measured p50 RTT",
      "p99Us": 56.7
    },
    {
      "id": "nvme-8k-read",
      "operation": "Local NVMe 8 KiB Random Read (GCP C4)",
      "category": "local-nvme",
      "latencyUs": 100,
      "maxQd1Ops": 10000,
      "transferTaxPerGbUsd": 0,
      "scopeNote": "S32 rounded 100 µs 8 KiB SSD reference, not a PM1763 measurement. No p99 is supplied.",
      "sourceRef": "S32",
      "statistic": "Rounded reference"
    },
    {
      "id": "i8g-128k-read",
      "operation": "AWS I8g Local NVMe 128 KiB QD1 Read",
      "category": "local-nvme",
      "latencyUs": 243.11,
      "maxQd1Ops": 4113,
      "transferTaxPerGbUsd": 0,
      "scopeNote": "December 2024 I8g fio 128 KiB random-read QD1 test: mean completion latency 243.11 µs; not a p50 and not a 2026 hardware measurement.",
      "sourceRef": "S31",
      "statistic": "Measured mean completion"
    },
    {
      "id": "nvme-fsync",
      "operation": "SSD fsync reference (8 KiB)",
      "category": "local-nvme",
      "latencyUs": 300,
      "maxQd1Ops": 3333,
      "transferTaxPerGbUsd": 0,
      "scopeNote": "S32 rounded 300 µs fsync reference; not a PostgreSQL transaction or replicated commit latency.",
      "sourceRef": "S32, S50",
      "statistic": "Rounded reference"
    },
    {
      "id": "io2-block-express",
      "operation": "io2 advertised average target",
      "category": "block-storage",
      "latencyUs": 500,
      "maxQd1Ops": 2000,
      "transferTaxPerGbUsd": 0,
      "scopeNote": "AWS advertises average latency under 500 µs for 16 KiB I/O. The chart plots the 500 µs boundary, not a measured mean or percentile.",
      "sourceRef": "S27",
      "statistic": "Advertised upper target"
    },
    {
      "id": "cross-az-rtt",
      "operation": "Cross-AZ Wire RTT (Before App/RPC Work)",
      "category": "cross-az",
      "latencyUs": 590.4,
      "maxQd1Ops": 1694,
      "transferTaxPerGbUsd": 0.02,
      "scopeNote": "590.4 µs wire RTT + $0.02/GB one-way ($0.04/GB bidirectional) across AWS AZs.",
      "sourceRef": "S30, S34",
      "statistic": "Measured p50 RTT",
      "p99Us": 677.4
    }
  ],
  "myths": [
    {
      "id": "postgres-over-redis",
      "category": "cache-queues",
      "categoryLabel": "Caching & Queues",
      "chapterRefs": "Ch. 03, 06, 16",
      "title": "1. Measure Before Adding a Remote Cache",
      "dogma2016": "Put a distributed Redis/Memcached cluster in front of PostgreSQL on day one because disk reads take 10 ms.",
      "reality2026": "Compare the complete cached and uncached paths, including miss behavior, serialization, invalidation, and failure recovery. A remote cache is not automatically faster than a local indexed read.",
      "verdictBadge": "Plan for a cold cache",
      "summary": "A cache is useful when measured latency, origin capacity, or cost justifies its consistency and recovery work.",
      "whyItChanged": [
        "A specific us-west-2 ENA Express test measured 52.2 µs same-AZ and 590.4 µs cross-AZ p50 RTT; these are not universal cache latencies.",
        "Local SSD reference timings exclude query execution. Benchmark the complete request, including cache misses."
      ],
      "whenYouStillNeedIt": [
        "Expensive computations, shared hot objects, or origin protection justify a cache when its failure and consistency behavior are acceptable."
      ],
      "sourceRefs": "S30, S32, S57",
      "scenario": {
        "metric": "Backend requests at a fixed arrival rate",
        "before": "95% hits: 5% reach origin",
        "after": "Cold cache: 100% reach origin",
        "assumption": "Assume every miss reaches the origin, no request coalescing, and unchanged incoming traffic. 100% / 5% = 20× origin requests; this does not predict database capacity."
      }
    },
    {
      "id": "scale-up-before-sharding",
      "category": "storage-db",
      "categoryLabel": "Database & Storage",
      "chapterRefs": "Ch. 01, 05, 13",
      "title": "2. Size Up Before Committing to Capacity Shards",
      "dogma2016": "Horizontally shard your relational database at 500 GB or 10,000 QPS using application-level shard routers or Vitess.",
      "reality2026": "Check available single-instance capacity and benchmark the data model before adding shards. Larger hosts do not eliminate availability, contention, or failure-domain requirements.",
      "verdictBadge": "6× size-level capacity",
      "summary": "Hardware capacity can postpone capacity sharding; tenant isolation and geographic distribution can still require partitions.",
      "whyItChanged": [
        "AWS publishes these size-specific CPU and memory limits; they do not prove a transaction or query rate.",
        "Sharding adds routing and cross-shard transaction work; a larger host still needs a recovery design."
      ],
      "whenYouStillNeedIt": [
        "The measured working set or write path exceeds one host, or isolation, geography, and failure containment require partitions."
      ],
      "sourceRefs": "S10, S38, S53",
      "scenario": {
        "metric": "M9g instance specifications",
        "before": "8xlarge: 32 vCPU / 128 GiB",
        "after": "48xlarge: 192 vCPU / 768 GiB",
        "assumption": "Same instance family: 6× CPU and memory, not a 6× application throughput claim. M9g is EBS-only. Costs, storage, and failover are separate."
      }
    },
    {
      "id": "skip-locked-over-kafka",
      "category": "cache-queues",
      "categoryLabel": "Caching & Queues",
      "chapterRefs": "Ch. 06, 17",
      "title": "3. A Broker Is a Requirement Decision",
      "dogma2016": "Deploy a multi-broker Kafka or RabbitMQ cluster for every background job queue, webhook processor, or transactional outbox.",
      "reality2026": "For a local job queue, a PostgreSQL transaction can store business state and job intent together. SKIP LOCKED can support workers; it does not replace every broker feature.",
      "verdictBadge": "One atomic local transaction",
      "summary": "Choose retention, replay, fan-out, ordering, and consumer isolation explicitly. Kafka 4.0 uses KRaft rather than ZooKeeper.",
      "whyItChanged": [
        "SKIP LOCKED avoids waiting on locked rows but provides an inconsistent view suitable for some queue-like tables.",
        "Kafka remains appropriate for a retained stream; removing a broker is not a universal simplification."
      ],
      "whenYouStillNeedIt": [
        "Independent replay, durable fan-out, high sustained throughput, or consumer isolation warrants a dedicated broker."
      ],
      "sourceRefs": "S59, S60, S69, S70",
      "scenario": {
        "metric": "Business update plus job intent",
        "before": "Two independent writes can diverge",
        "after": "One database transaction commits both",
        "assumption": "State and queue row share one PostgreSQL database. External side effects still need idempotency; pollers and queue tables add database load."
      }
    },
    {
      "id": "unified-pg-over-frankenstack",
      "category": "search-logs-ai",
      "categoryLabel": "Search, Logs & AI",
      "chapterRefs": "Ch. 05, 22, 23",
      "title": "4. Search Does Not Always Need a Separate Database",
      "dogma2016": "Run Postgres (OLTP) + Elasticsearch (BM25 search) + Pinecone/Milvus (vectors) + MongoDB (JSON) + Redis (cache) with CDC glue.",
      "reality2026": "PostgreSQL offers text search and JSONB; pgvector adds exact, HNSW, and IVFFlat vector search. Evaluate recall, filtering, ranking, and write overhead before selecting a separate engine.",
      "verdictBadge": "Measure recall and filtering",
      "summary": "Keeping an index near transactional data can remove a replication pipeline, but index maintenance and query isolation still cost resources.",
      "whyItChanged": [
        "pgvector implements HNSW and IVFFlat; DiskANN is not a built-in pgvector index.",
        "Approximate indexes trade recall and resource use; filtered results need workload-specific evaluation."
      ],
      "whenYouStillNeedIt": [
        "A dedicated engine meets measured ranking, corpus size, update, filtering, or isolation needs better."
      ],
      "sourceRefs": "S67",
      "scenario": {
        "metric": "Raw vector payload lower bound",
        "before": "20M × 1,536 × 4 bytes",
        "after": "122.88 GB before index overhead",
        "assumption": "Float32 payload only. Excludes tuple headers, HNSW graph, metadata, replicas, and build space. No QPS, recall, or RAM-fit guarantee."
      }
    },
    {
      "id": "zonal-affinity-cells",
      "category": "sharding-rpc",
      "categoryLabel": "Sharding & Services",
      "chapterRefs": "Ch. 11, 14, 15",
      "title": "5. Price the Actual Cross-Zone Path",
      "dogma2016": "Decompose into 40 microservices calling each other round-robin across 3 Availability Zones over REST/JSON.",
      "reality2026": "Use zonal affinity where it preserves the required fault tolerance. Price each endpoint and service-specific path; do not remove durability replication to save transfer fees.",
      "verdictBadge": "$97,901 for this traffic model",
      "summary": "Bandwidth, round-trip latency, and transfer billing are separate inputs.",
      "whyItChanged": [
        "A measured 590.4 µs cross-AZ p50 RTT comes from one us-west-2 test, not every region or host.",
        "Same-zone routing must include a tested failover path and adequate capacity in surviving zones."
      ],
      "whenYouStillNeedIt": [
        "Synchronous replication, zone failure tolerance, or a required dependency justifies the cross-zone path and cost."
      ],
      "sourceRefs": "S30, S34, S35, S45, S57",
      "scenario": {
        "metric": "Ordinary EC2 cross-AZ payload transfer",
        "before": "2 GB/s × 730 h",
        "after": "4,895,031 GiB × $0.02 ≈ $97,901",
        "assumption": "Decimal GB/s; binary billed GiB; 730-hour month; $0.01/GiB at each ordinary EC2 endpoint. One-way payload only, no return payload, exemptions, discounts, or protocol overhead."
      }
    },
    {
      "id": "s3-parquet-over-saas-logs",
      "category": "search-logs-ai",
      "categoryLabel": "Search, Logs & AI",
      "chapterRefs": "Ch. 19, 20, 21",
      "title": "6. Separate Log Ingestion from Retention Cost",
      "dogma2016": "Ship 100% of raw un-sampled application logs to a SaaS observability vendor or a 30-node stateful Elasticsearch hot cluster.",
      "reality2026": "Choose sampling, retention, storage, and query latency separately. Object storage plus an analytical engine can fit some workloads, but storage price is not the total cost of observability.",
      "verdictBadge": "State the cost boundary",
      "summary": "Avoid comparing a full managed service invoice with only the storage component of a replacement.",
      "whyItChanged": [
        "Compression is workload dependent; benchmark your actual log format.",
        "Retained volume is not automatically the average stored volume during an initially empty first month."
      ],
      "whenYouStillNeedIt": [
        "Low-latency search, alerting, audited retention, or managed operations justify a specialized observability service."
      ],
      "sourceRefs": "S39, S43",
      "scenario": {
        "metric": "One model month of compressed retention",
        "before": "100k lines/s × 1,000 B × 730 h",
        "after": "262.8 TB raw / 5 = 52.56 TB stored",
        "assumption": "Assumed constant rate and 5:1 compression; 52.56 decimal TB = 48,950.31 GiB. One full retained model month at $0.023/GiB-month is $1,125.86. Excludes ingestion, queries, requests, indexing, replication, and transfer."
      }
    },
    {
      "id": "nosql-to-acid-sql",
      "category": "storage-db",
      "categoryLabel": "Database & Storage",
      "chapterRefs": "Ch. 05, 09, 10, 11",
      "title": "7. Choose Database Semantics, Not a SQL/NoSQL Label",
      "dogma2016": "Assume every SQL database has identical consistency, and every NoSQL database sacrifices transactions for write scale.",
      "reality2026": "Specify isolation, conflict handling, durability acknowledgments, and partition behavior for the selected product and configuration. Neither SQL nor NoSQL branding defines these guarantees.",
      "verdictBadge": "Name the isolation level",
      "summary": "A fast storage device cannot repair a lost update or enforce an unstated business invariant.",
      "whyItChanged": [
        "WAL and group commit improve the write path but do not establish a database-wide TPS ceiling.",
        "Concurrent correctness depends on constraints and isolation, not sequential disk bandwidth."
      ],
      "whenYouStillNeedIt": [
        "A key-value, document, relational, or distributed database is appropriate when its documented semantics and measured workload fit."
      ],
      "sourceRefs": "S50, S60",
      "scenario": {
        "metric": "PostgreSQL default isolation",
        "before": "Read Committed",
        "after": "Serializable when the invariant needs it",
        "assumption": "PostgreSQL 18 defaults to Read Committed. Serializable can abort transactions; retry the complete transaction and handle external effects safely."
      }
    },
    {
      "id": "gp3-local-nvme-over-io2",
      "category": "storage-db",
      "categoryLabel": "Database & Storage",
      "chapterRefs": "Ch. 03, 07",
      "title": "8. Provision EBS for the Required Performance",
      "dogma2016": "Provision maxed-out enterprise SAN / io2 volumes for every database, or assume cloud block storage can deliver 2,000 MiB/s at 4-KiB random I/O.",
      "reality2026": "Price volume capacity and provisioned performance separately. gp3 and io2 have different performance and durability characteristics; neither price proves the other meets the workload.",
      "verdictBadge": "$542 versus $9,824, unequal tiers",
      "summary": "A cheaper provisioned volume is useful only if its latency, IOPS, throughput, and durability fit the application.",
      "whyItChanged": [
        "Check instance EBS bandwidth and supported volume limits as well as the volume specification.",
        "Peak IOPS depends on I/O size and concurrency; average latency targets are not p99 guarantees."
      ],
      "whenYouStillNeedIt": [
        "io2 is appropriate when its documented durability, latency, or provisioned IOPS is required."
      ],
      "sourceRefs": "S26, S27, S41, S42",
      "scenario": {
        "metric": "N. Virginia: one 1 TiB volume",
        "before": "io2: 256k IOPS ≈ $9,824/month",
        "after": "gp3: 80k IOPS + 2,000 MiB/s ≈ $542/month",
        "assumption": "gp3: 1024×$0.08 + (80000−3000)×$0.005 + (2000−125)×$0.04 = $541.92. io2: 1024×$0.125 + 32000×$0.065 + 32000×$0.046 + 192000×$0.032 = $9,824. Unequal provisioned performance; excludes snapshots and compute."
      }
    },
    {
      "id": "fencing-tokens-over-redlock",
      "category": "cache-queues",
      "categoryLabel": "Caching & Queues",
      "chapterRefs": "Ch. 10, 12",
      "title": "9. A Lease Needs Protection at the Resource",
      "dogma2016": "Run a 5-node Redis Redlock cluster with wall-clock TTL leases to guarantee mutually exclusive distributed locks.",
      "reality2026": "A paused lease holder can resume after its lease expires. Where correctness depends on ownership, the resource must reject stale fencing tokens, or use an atomic conditional update suited to the invariant.",
      "verdictBadge": "Reject stale writers",
      "summary": "A lock timeout does not stop the old process. Fencing and compare-and-swap solve related but distinct problems.",
      "whyItChanged": [
        "A process pause can outlast a lease while the process still believes it owns the resource.",
        "A conditional database update can protect a single state transition; it does not automatically fence external effects."
      ],
      "whenYouStillNeedIt": [
        "Distributed coordination is necessary and the protected resource can enforce its ownership contract."
      ],
      "sourceRefs": "S60, S66, S71",
      "scenario": {
        "metric": "Monotonic fencing epoch",
        "before": "Writer with epoch 41 pauses",
        "after": "Resource accepts 42, then rejects 41",
        "assumption": "A trusted authority issues monotonically increasing epochs. Every protected operation checks the epoch at the resource. An ETag or expected-version comparison is per-object compare-and-swap, not automatically a fencing protocol."
      }
    },
    {
      "id": "url-shortener-1-node",
      "category": "sharding-rpc",
      "categoryLabel": "Sharding & Services",
      "chapterRefs": "Ch. 27, 28, 29",
      "title": "10. Start a URL Shortener with Workload Arithmetic",
      "dogma2016": "Start every URL shortener with an ID service, a sharded database, a cache cluster, and a broker before estimating its traffic.",
      "reality2026": "Translate monthly totals into average rates, then measure peak demand, skew, redirects, durability, and abuse controls before adding shards or caches.",
      "verdictBadge": "38 writes/s is an average",
      "summary": "Average traffic is a starting point, not a peak-capacity or availability guarantee.",
      "whyItChanged": [
        "Monthly request counts alone do not determine fleet size or CPU utilization.",
        "Caching redirects requires explicit expiry, deletion, security, and analytics semantics."
      ],
      "whenYouStillNeedIt": [
        "Measured peaks, geographic latency, or a large hot working set justify additional capacity or caches."
      ],
      "sourceRefs": "S10, S56, S57",
      "scenario": {
        "metric": "100M writes and 10B reads per model month",
        "before": "730 h = 2,628,000 s",
        "after": "38.05 writes/s; 3,805.18 reads/s",
        "assumption": "Uniform arrival assumption for averages only. Burst factors, hot keys, query cost, payloads, replication, and failure reserve need separate estimates."
      }
    },
    {
      "id": "retry-budgets",
      "category": "sharding-rpc",
      "categoryLabel": "Sharding & Services",
      "chapterRefs": "Ch. 15, 31",
      "title": "11. Retries Need a Budget, Not Another Layer",
      "dogma2016": "Retry every timeout three times at the gateway, service, and database client; more retries mean higher availability.",
      "reality2026": "Retries multiply across layers. Assign retry ownership, propagate deadlines, add jitter, and make mutations idempotent before retrying.",
      "verdictBadge": "64 attempts from 1 request",
      "summary": "Faster servers cannot absorb unlimited retry amplification. A timeout leaves the outcome unknown; it does not prove a write failed.",
      "scenario": {
        "metric": "Worst-case downstream attempts",
        "before": "4 × 4 × 4 = 64",
        "after": "1 retry owner: at most 4",
        "assumption": "Three layers; each permits an initial attempt plus three retries. All attempts fail. Single-owner budget also depends on the remaining deadline."
      },
      "whyItChanged": [
        "Three independent retry layers can turn 1,000 incoming requests into 64,000 downstream attempts in this failure scenario.",
        "Backoff spreads attempts over time; jitter reduces synchronized bursts. Neither makes duplicate side effects safe."
      ],
      "whenYouStillNeedIt": [
        "The failure is transient, the operation is idempotent, and another attempt fits the deadline and retry budget."
      ],
      "sourceRefs": "S56"
    },
    {
      "id": "static-stability",
      "category": "sharding-rpc",
      "categoryLabel": "Sharding & Services",
      "chapterRefs": "Ch. 02, 14, 31",
      "title": "12. Autoscaling Is Not Your AZ-Failure Plan",
      "dogma2016": "Run all three zones near full utilization; the autoscaler will replace capacity after a zone fails.",
      "reality2026": "Pre-provision surviving capacity for the failure you promise to tolerate. Keep the data plane working while scaling APIs or schedulers are unavailable.",
      "verdictBadge": "2.143× capacity in this model",
      "summary": "Capacity planning must use peak demand, failure domains, and a measured safe utilization ceiling.",
      "scenario": {
        "metric": "Capacity relative to peak demand D",
        "before": "1.5D → 100% after AZ loss",
        "after": "2.143D → 70% after AZ loss",
        "assumption": "Three equal zones; one lost; survivors must stay at or below an assumed 70% utilization. C ≥ D / ((2/3) × 0.70). This is not a universal utilization target."
      },
      "whyItChanged": [
        "At 2.143D total capacity, normal utilization is about 46.7%; losing one third raises it to 70%.",
        "Load-test the surviving fleet, including connection pools, cache warm-up, storage, and downstream limits."
      ],
      "whenYouStillNeedIt": [
        "Autoscaling handles gradual growth or recovery after the pre-provisioned fleet absorbs an immediate failure."
      ],
      "sourceRefs": "S57"
    },
    {
      "id": "bounded-concurrency",
      "category": "sharding-rpc",
      "categoryLabel": "Sharding & Services",
      "chapterRefs": "Ch. 14, 17, 31",
      "title": "13. Low CPU Does Not Mean Spare Capacity",
      "dogma2016": "Scale on CPU alone and keep an unbounded request queue so every request eventually succeeds.",
      "reality2026": "Bound in-flight work, shed excess load, propagate cancellation, and measure successful responses completed before their deadlines.",
      "verdictBadge": "10 → 1,000 in flight",
      "summary": "A slow dependency can exhaust connections and memory while application CPU sits idle.",
      "scenario": {
        "metric": "Mean in-flight requests (L = λW)",
        "before": "2,000/s × 5 ms = 10",
        "after": "2,000/s × 500 ms = 1,000",
        "assumption": "Steady-state illustration using mean arrival rate and mean time in the system. It predicts required concurrency, not a p99 latency."
      },
      "whyItChanged": [
        "The same arrival rate requires 100× more in-flight capacity when mean residency time grows by 100×.",
        "Set admission limits from load tests and dependency budgets; an unbounded queue stores latency and memory pressure."
      ],
      "whenYouStillNeedIt": [
        "A bounded durable queue is appropriate for asynchronous work whose deadline permits waiting."
      ],
      "sourceRefs": "S56, S58"
    },
    {
      "id": "queue-drain-rate",
      "category": "cache-queues",
      "categoryLabel": "Caching & Queues",
      "chapterRefs": "Ch. 17, 31",
      "title": "14. Queue Depth Is Not a Recovery-Time Estimate",
      "dogma2016": "Add a durable queue and let workers catch up later; backlog size alone tells us whether the service is healthy.",
      "reality2026": "Track oldest-message age and net drain rate. Recovery requires service rate greater than incoming work, including retries.",
      "verdictBadge": "500 s to drain this backlog",
      "summary": "A queue buys time only when consumers have enough spare throughput to recover before retention or business deadlines expire.",
      "scenario": {
        "metric": "Backlog / spare throughput",
        "before": "1M jobs at μ = λ: never drains",
        "after": "1M / (12k − 10k) = 500 s",
        "assumption": "A fixed initial backlog of one million jobs; sustained arrival 10,000/s; sustained completion 12,000/s; no new failures or capacity changes."
      },
      "whyItChanged": [
        "With arrivals continuing, dividing backlog by the full 12,000/s service rate understates recovery time.",
        "Monitor dead-letter queues and retry counts alongside age: poison messages can distort an oldest-message metric."
      ],
      "whenYouStillNeedIt": [
        "A managed broker provides durable buffering, fan-out, or independent consumers; size retention and recovery capacity explicitly."
      ],
      "sourceRefs": "S58"
    },
    {
      "id": "idempotency-over-exactly-once",
      "category": "cache-queues",
      "categoryLabel": "Caching & Queues",
      "chapterRefs": "Ch. 09, 17, 29, 31",
      "title": "15. Exactly-Once Delivery Does Not Make Payments Exactly Once",
      "dogma2016": "Select an exactly-once broker and remove duplicate handling from consumers and external side effects.",
      "reality2026": "Define the guarantee boundary. Store a business idempotency key atomically with the state change; propagate a stable key to external providers and reconcile unknown outcomes.",
      "verdictBadge": "Deduplicate business effects",
      "summary": "Delivery guarantees apply within a boundary. A database update, broker acknowledgment, and external charge do not automatically share one transaction.",
      "scenario": {
        "metric": "One business effect, repeated delivery",
        "before": "2 deliveries can charge twice",
        "after": "1 key → 1 committed local effect",
        "assumption": "Local database transaction with a unique (tenant_id, idempotency_key) constraint. External payment effects need provider idempotency or reconciliation too."
      },
      "whyItChanged": [
        "A worker can commit a business update and crash before acknowledging a message; redelivery must be safe.",
        "An outbox makes a local state change and publication intent atomic; publication and consumption can still repeat."
      ],
      "whenYouStillNeedIt": [
        "Broker transactions are useful within their documented scope; consumers must still handle effects outside that scope."
      ],
      "sourceRefs": "S59, S60"
    },
    {
      "id": "uuidv7-over-id-fleet",
      "category": "sharding-rpc",
      "categoryLabel": "Sharding & Services",
      "chapterRefs": "Ch. 12, 27",
      "title": "16. Most IDs Do Not Need a Snowflake Service",
      "dogma2016": "Every scalable service needs a dedicated ID fleet, coordinated worker IDs, and ZooKeeper.",
      "reality2026": "Use a database sequence or UUIDv7 when those semantics fit. PostgreSQL 18 provides uuidv7(); timestamp ordering is not a global commit-order guarantee.",
      "verdictBadge": "Generate IDs locally",
      "summary": "Choose identifiers for uniqueness, locality, privacy, and ordering requirements before adding an always-available coordination service.",
      "scenario": {
        "metric": "128-bit IDs, local generation",
        "before": "Worker-ID coordination",
        "after": "48 timestamp bits + 74 remaining bits",
        "assumption": "UUIDv7 also reserves six version/variant bits. The remaining 74 bits can encode randomness and optional sub-millisecond or counter fields; collision behavior depends on implementation."
      },
      "whyItChanged": [
        "The time prefix generally improves insertion locality compared with random UUIDv4; it does not eliminate B-tree splits.",
        "Keep a uniqueness constraint. UUIDv7 exposes approximate creation time and is not an authorization secret."
      ],
      "whenYouStillNeedIt": [
        "A compact 64-bit format, strict global sequencing, or gap-free business numbering is a real requirement."
      ],
      "sourceRefs": "S61, S62"
    },
    {
      "id": "keyset-over-offset",
      "category": "storage-db",
      "categoryLabel": "Database & Storage",
      "chapterRefs": "Ch. 08, 15, 18",
      "title": "17. Deep Pagination Needs an Index and a Cursor",
      "dogma2016": "LIMIT 50 OFFSET 1000000 costs roughly the same as page one because the database has an index.",
      "reality2026": "Skipped rows still require work. Seek from a stable composite key such as (created_at, id), with a matching index and explicit ordering.",
      "verdictBadge": "Seek instead of skip",
      "summary": "A matching index and stable cursor can reduce traversal work without requiring a cache or a larger database.",
      "scenario": {
        "metric": "Idealized index entries visited",
        "before": "1,000,050 for OFFSET + LIMIT",
        "after": "About 50 after a cursor seek",
        "assumption": "Matching B-tree access path with no additional filtering; excludes tree traversal, MVCC checks, and heap fetches. Work estimate, not a latency benchmark."
      },
      "whyItChanged": [
        "A deep offset walks past entries before returning the requested rows; a keyset predicate can begin near the cursor.",
        "Use a unique tie-breaker and fixed sort direction. A changing sort key or different snapshots can still cause pagination anomalies."
      ],
      "whenYouStillNeedIt": [
        "Small admin tables or random page-number jumps justify OFFSET and its measured cost."
      ],
      "sourceRefs": "S63"
    },
    {
      "id": "isolation-over-acid-label",
      "category": "storage-db",
      "categoryLabel": "Database & Storage",
      "chapterRefs": "Ch. 09, 29",
      "title": "18. ACID Is Not an Isolation-Level Specification",
      "dogma2016": "A transaction in an ACID database automatically protects every cross-row business invariant.",
      "reality2026": "Choose constraints, row locks, or serializable isolation for the actual invariant. PostgreSQL defaults to Read Committed; serializable transactions can abort and require a whole-transaction retry.",
      "verdictBadge": "Protect the actual invariant",
      "summary": "Database branding does not specify which concurrent histories the selected isolation level permits.",
      "scenario": {
        "metric": "Write-skew example",
        "before": "2 doctors read 2 on call; both leave",
        "after": "Enforce at least 1 on call",
        "assumption": "Each transaction updates a different doctor after checking the count. No row is shared for locking; use a shared guard row or serializable isolation and retry."
      },
      "whyItChanged": [
        "Snapshot-based reads alone do not serialize transactions that write different rows after reading a shared predicate.",
        "A unique constraint is simpler for uniqueness; choose an isolation mechanism for the invariant you actually need."
      ],
      "whenYouStillNeedIt": [
        "Read Committed is sufficient when constraints and atomic updates fully enforce the business rules."
      ],
      "sourceRefs": "S60"
    },
    {
      "id": "replicas-are-not-backups",
      "category": "storage-db",
      "categoryLabel": "Database & Storage",
      "chapterRefs": "Ch. 06, 11, 31",
      "title": "19. Three Replicas Are Not Three Backups",
      "dogma2016": "Replicate the database three ways and skip backup restores; any replica can recover lost data.",
      "reality2026": "Replication also propagates bad writes and deletes. Keep independent recovery history, define RPO/RTO, and rehearse point-in-time restores.",
      "verdictBadge": "Test the restore path",
      "summary": "More live copies improve availability but can faithfully reproduce the same operator mistake.",
      "scenario": {
        "metric": "Idealized restore transfer lower bound",
        "before": "10 TB / 1 GB/s = 2 h 47 min",
        "after": "10 TB / 5 GB/s = 33 min 20 s",
        "assumption": "Decimal TB and GB/s; sustained end-to-end throughput. Excludes provisioning, WAL replay, validation, index work, and application recovery."
      },
      "whyItChanged": [
        "A replica may offer fast failover without preserving a state before an accidental deletion.",
        "A complete recovery drill includes credentials, backup access, WAL continuity, consistency checks, and traffic cutover."
      ],
      "whenYouStillNeedIt": [
        "Replicas meet availability and read-scaling needs; retain independently recoverable backups as well."
      ],
      "sourceRefs": "S51, S64"
    },
    {
      "id": "local-nvme-durability",
      "category": "storage-db",
      "categoryLabel": "Database & Storage",
      "chapterRefs": "Ch. 03, 06, 11",
      "title": "20. Fast Local NVMe Does Not Imply Durable Storage",
      "dogma2016": "A local NVMe fsync and a large SSD are enough to replace durable replicated database storage.",
      "reality2026": "An fsync protects a local write within the device contract. Instance-store data can disappear on stop, termination, or hardware loss; replication acknowledgments and tested backups define recovery.",
      "verdictBadge": "Define the acknowledgment",
      "summary": "Performance estimates must include what survives a host failure after the client receives success.",
      "scenario": {
        "metric": "Acknowledged-write recovery target",
        "before": "Local-only: host loss can lose data",
        "after": "RPO depends on replication policy",
        "assumption": "RPO is the amount of accepted data you may lose. Synchronous durability also depends on replica placement, acknowledgment configuration, fencing, and failover selection."
      },
      "whyItChanged": [
        "Local storage performance is a useful building block, not a proof of availability or durability.",
        "Do not infer a database commit rate from sequential SSD bandwidth: WAL, contention, fsync, and replication all matter."
      ],
      "whenYouStillNeedIt": [
        "Ephemeral caches, rebuildable indexes, or replicated databases have an explicit recovery and durability design."
      ],
      "sourceRefs": "S50, S51, S52, S53"
    },
    {
      "id": "s3-strong-consistency",
      "category": "storage-db",
      "categoryLabel": "Database & Storage",
      "chapterRefs": "Ch. 10, 11, 19",
      "title": "21. S3 Is Not Eventually Consistent for Every Operation",
      "dogma2016": "Object storage always needs sleeps and a separate metadata database to hide stale reads after every write.",
      "reality2026": "S3 documents strong consistency for object PUT/DELETE and subsequent GET/LIST. That does not provide a transaction across multiple keys or make cross-region replication synchronous.",
      "verdictBadge": "Strong per-object consistency",
      "summary": "Remove obsolete stale-read workarounds only after checking the exact operation and atomicity boundary.",
      "scenario": {
        "metric": "Atomicity boundary",
        "before": "Many objects in a dataset",
        "after": "Conditional update of one object",
        "assumption": "General-purpose S3 object semantics; use documented If-Match/If-None-Match support for each operation. A table format needs its own metadata commit protocol."
      },
      "whyItChanged": [
        "A conditional update can reject a stale ETag; a read-modify-write without a condition can still overwrite a concurrent writer.",
        "Strong consistency does not turn LIST plus several PUTs into one atomic commit."
      ],
      "whenYouStillNeedIt": [
        "A database or catalog is needed for multi-record transactions, secondary indexes, or coordinated dataset publication."
      ],
      "sourceRefs": "S65, S66"
    },
    {
      "id": "vector-memory-budget",
      "category": "search-logs-ai",
      "categoryLabel": "Search, Logs & AI",
      "chapterRefs": "Ch. 03, 23, 26",
      "title": "22. Vector Count Is Not a Memory Budget",
      "dogma2016": "Ten million embeddings always require a dedicated vector database, and approximate indexes preserve exact recall.",
      "reality2026": "Estimate dimensions, precision, index overhead, filters, and replicas first. pgvector supports exact and approximate search; HNSW trades memory and build cost for query speed and recall.",
      "verdictBadge": "61.44 GB of raw float32 data",
      "summary": "Raw embedding size is straightforward arithmetic; production index sizing and retrieval quality require measurement.",
      "scenario": {
        "metric": "Raw 10M × 1,536-dimensional vectors",
        "before": "Float32: 61.44 GB (57.22 GiB)",
        "after": "Float16: 30.72 GB (28.61 GiB)",
        "assumption": "Payload only at 4 versus 2 bytes per dimension. Excludes row headers, HNSW graph, metadata, replicas, and temporary build space; reduced precision needs quality evaluation."
      },
      "whyItChanged": [
        "A raw vector-size estimate is a lower bound, not an HNSW capacity claim.",
        "Approximate-index filtering can return fewer results. Measure recall@k and filtered latency against an exact-search reference."
      ],
      "whenYouStillNeedIt": [
        "A dedicated engine fits measured corpus size, update rate, tenant filters, recall, and operational requirements better."
      ],
      "sourceRefs": "S67"
    },
    {
      "id": "little-law-llm-serving",
      "category": "search-logs-ai",
      "categoryLabel": "Search, Logs & AI",
      "chapterRefs": "Ch. 24, 25, 26, 31",
      "title": "23. Token Throughput Is Not an LLM Latency SLO",
      "dogma2016": "Choose an inference service by aggregate tokens per second; that number predicts every user experience.",
      "reality2026": "Measure time to first token, inter-token latency, end-to-end completion time, and concurrent sequence memory at your prompt/output lengths and arrival rate.",
      "verdictBadge": "40 → 400 concurrent sequences",
      "summary": "Serving economics depend on how long sequences occupy capacity, not just a peak token-throughput figure.",
      "scenario": {
        "metric": "Mean concurrent generations",
        "before": "20 req/s × 2 s = 40",
        "after": "20 req/s × 20 s = 400",
        "assumption": "Steady-state mean arrival rate and mean generation residency time; includes waiting if measured end to end. This is concurrency math, not a GPU throughput benchmark."
      },
      "whyItChanged": [
        "Ten times longer residence at the same arrival rate requires ten times more concurrent sequences or admission backpressure.",
        "Separate prefill from decode load; benchmark representative context lengths and quantization quality rather than quoting a peak token rate."
      ],
      "whenYouStillNeedIt": [
        "Batch throughput is the objective for offline work whose completion deadline and quality requirements are satisfied."
      ],
      "sourceRefs": "S68"
    },
    {
      "id": "fanout-tail-budget",
      "category": "sharding-rpc",
      "categoryLabel": "Sharding & Services",
      "chapterRefs": "Ch. 14, 28, 31",
      "title": "24. A p99 Dependency Does Not Make a p99 Endpoint",
      "dogma2016": "If each of 100 parallel dependencies meets its latency budget 99% of the time, the endpoint does too.",
      "reality2026": "All-required fan-out compounds tail risk. Budget the entire critical path, reduce synchronous dependencies, and make partial results explicit where the product permits them.",
      "verdictBadge": "63.4% exceedance in this model",
      "summary": "An endpoint waiting on every dependency inherits the slowest required result.",
      "scenario": {
        "metric": "Probability all calls meet a threshold",
        "before": "100 independent calls: 0.99^100",
        "after": "Only 36.6% meet it together",
        "assumption": "All 100 calls are required and have independent, identical 1% threshold-exceedance probability. Correlated failures require a different model; this does not predict the endpoint p99."
      },
      "whyItChanged": [
        "The chance at least one call exceeds the threshold is 1 − 0.99^100, about 63.4%.",
        "Parallelism shortens some paths but does not remove the slowest required dependency from the request deadline."
      ],
      "whenYouStillNeedIt": [
        "Fan-out is necessary and the endpoint has an explicit timeout, concurrency budget, and partial-failure contract."
      ],
      "sourceRefs": "S56"
    }
  ],
  "archetypes": [
    {
      "id": "web-api-1m-rps",
      "name": "Cross-Zone Routing",
      "workloadLabel": "2 GB/s; 730 hours",
      "legacyStackName": "Assumed option A",
      "modernStackName": "Assumed option B",
      "legacyMonthlyUsd": 111614,
      "modernMonthlyUsd": 13713,
      "legacyMovingParts": 2,
      "modernMovingParts": 2,
      "legacyComponents": [
        "Assume two m9g.48xlarge nodes: $13,713.25/month.",
        "One ordinary EC2 cross-AZ payload path: $97,900.63/month."
      ],
      "modernComponents": [
        "Same two compute nodes: $13,713.25/month.",
        "Assume this payload path stays within a zone."
      ],
      "mathNote": "Worked budget, not historical stacks: 2×$9.39264×730 + 2e9×2,628,000/2^30×$0.02 versus the same compute alone [S34, S38, S45]. Excludes public egress, storage, replication and failover costs. Routing must preserve the required availability."
    },
    {
      "id": "financial-ledger-10k-tps",
      "name": "Provisioned Block Storage",
      "workloadLabel": "3 × 1 TiB volumes",
      "legacyStackName": "Assumed option A",
      "modernStackName": "Assumed option B",
      "legacyMonthlyUsd": 29472,
      "modernMonthlyUsd": 1626,
      "legacyMovingParts": 3,
      "modernMovingParts": 3,
      "legacyComponents": [
        "Three io2 volumes, each provisioned for 256k IOPS: 3×$9,824."
      ],
      "modernComponents": [
        "Three gp3 volumes, each provisioned for 80k IOPS and 2,000 MiB/s: 3×$541.92."
      ],
      "mathNote": "Unequal performance tiers, not interchangeable storage or measured database stacks [S26, S27, S41]. Capacity, provisioned IOPS and throughput only; excludes compute, snapshots and replication transfer."
    },
    {
      "id": "observability-100k-logs",
      "name": "Log Cost Boundaries",
      "workloadLabel": "100k × 1kB lines/s",
      "legacyStackName": "Assumed option A",
      "modernStackName": "Assumed option B",
      "legacyMonthlyUsd": 122376,
      "modernMonthlyUsd": 1126,
      "legacyMovingParts": 1,
      "modernMovingParts": 1,
      "legacyComponents": [
        "Assumed ingestion-only rate: $0.50/GiB × 244,751.57 GiB. This is an input, not a vendor quote."
      ],
      "modernComponents": [
        "One retained model month, compressed 5:1: 48,950.31 GiB × $0.023/GiB-month."
      ],
      "mathNote": "Different cost boundaries, not a savings or feature-equivalence claim. Assumes 730 hours and 5:1 compression [S39, S43]. Ingestion and retention are different meters; the storage figure excludes collection, queries, requests and operations."
    },
    {
      "id": "ai-rag-search-20m",
      "name": "Compute Fleet Budget",
      "workloadLabel": "Assumed 4 vs 2 nodes",
      "legacyStackName": "Assumed option A",
      "modernStackName": "Assumed option B",
      "legacyMonthlyUsd": 4571,
      "modernMonthlyUsd": 2286,
      "legacyMovingParts": 4,
      "modernMovingParts": 2,
      "legacyComponents": [
        "Four m9g.8xlarge instances: 4×$1.56544×730 = $4,571.08."
      ],
      "modernComponents": [
        "Two m9g.8xlarge instances: 2×$1.56544×730 = $2,285.54."
      ],
      "mathNote": "Compute-only budget with assumed fleet counts [S10, S38]. Halving node count halves this meter; no throughput, availability, vector capacity or functional-equivalence claim. Benchmark before consolidating."
    }
  ],
  "rules": [
    {
      "num": 1,
      "title": "Model latency, bandwidth, and cost separately",
      "detail": "C8in advertises up to 600 Gbps; a separate c8gn test measured 590.4 µs cross-AZ p50 RTT. Ordinary EC2 cross-AZ payload is charged at both endpoints. These describe different limits and scopes.",
      "sourceRef": "S11, S30, S34"
    },
    {
      "num": 2,
      "title": "Large machines exist, but maxima are not one composite VM",
      "detail": "A 192-core Graviton5 VM (M9g), a 32-TiB memory instance (U7inh), and a 48-TB bare-metal server (GCP X5) are distinct SKUs.",
      "sourceRef": "S10, S13, S20"
    },
    {
      "num": 3,
      "title": "Distinguish component peaks from application throughput",
      "detail": "A 28.4 GB/s PCIe Gen6 SSD does not automatically establish database TPS; WAL fsync, locks, and indexes govern real throughput.",
      "sourceRef": "S03, S50"
    },
    {
      "num": 4,
      "title": "Check instance, per-flow, and destination network limits together",
      "detail": "AWS documents ordinary single-flow limits separately from aggregate instance bandwidth: up to 5 Gbps, up to 10 Gbps within a cluster placement group, or up to 25 Gbps with supported ENA Express. Check destination and instance exceptions.",
      "sourceRef": "S23, S24, S25"
    },
    {
      "num": 5,
      "title": "Treat AZ latency as a measured distribution, not a global constant",
      "detail": "52.2 µs same-AZ and 590.4 µs cross-AZ p50 RTT come from a specific c8gn.8xlarge ENA Express test in us-west-2.",
      "sourceRef": "S30"
    },
    {
      "num": 6,
      "title": "Never turn 1 / RTT into a database-wide TPS ceiling",
      "detail": "1 / 0.6 ms ≈ 1,667 operations/s describes idealized serialized operations with no other work. Batching and concurrency change aggregate throughput; neither this reciprocal nor disk bandwidth establishes database TPS.",
      "sourceRef": "S50, S51"
    },
    {
      "num": 7,
      "title": "Price memory and storage with dated SKU quotes",
      "detail": "Conventional DRAM contract prices rose 93–98% QoQ in Q1 2026, while cloud instance rates follow published provider price feeds.",
      "sourceRef": "S38, S46, S47, S48, S49"
    },
    {
      "num": 8,
      "title": "Compare storage at the actual I/O size and queue depth",
      "detail": "Compare fio block size, completion versus total latency, and queue depth. Azure Laosv5 documents 4 KB, QD256 peak tests; do not apply that queue depth to an unrelated Samsung drive claim.",
      "sourceRef": "S03, S16, S31"
    },
    {
      "num": 9,
      "title": "Include transfer, requests, retention, and restore in cost models",
      "detail": "The calculator uses a 730-hour month, N. Virginia rates, and binary billed units. Public egress tiers and allowances are shared with other eligible account usage; above 500 TB/month AWS invites custom pricing. Excludes NAT, load balancers, requests, database storage, discounts and tax.",
      "sourceRef": "S38, S40, S43"
    },
    {
      "num": 10,
      "title": "Design cells, quorums, and static stability explicitly",
      "detail": "For an assumed 730-hour month, 99.99% permits 262.8 s of downtime; 99.999% permits 26.28 s. Replication acknowledgments, fencing, failover selection and surviving capacity determine recovery; a zone count alone proves no SLA.",
      "sourceRef": "S51, S54"
    }
  ],
  "hardwareSpecs": [
    {
      "component": "AMD EPYC 9006 (Venice)",
      "verifiedSpec": "Up to 256 cores / 512 threads; 16-ch DDR5/MRDIMM up to 12,800 MT/s (~1.6 TB/s/socket); 128 lanes PCIe Gen6",
      "interpretation": "Platform-specific theoretical interface maximum; 16 × 12,800 MT/s × 8 B = 1,638.4 GB/s. Not measured application bandwidth.",
      "sourceRef": "S01, S02"
    },
    {
      "component": "AWS Graviton5 (M9g / M9gd)",
      "verifiedSpec": "192 cores, DDR5-8800, PCIe Gen6; GA 10 June 2026 (m9g.48xlarge: 192 vCPU, 768 GiB, $9.39264/hr = $6,856.63/mo)",
      "interpretation": "Production cloud compute in US East (N. Virginia); 100 Gbps network and 72 Gbps EBS on 48xlarge.",
      "sourceRef": "S10, S38"
    },
    {
      "component": "Samsung PM1763 (PCIe Gen6 SSD)",
      "verifiedSpec": "Catalogue: up to 28,400 MB/s sequential read, 21,000 MB/s write; 6.8M random-read IOPS and 950k random-write IOPS",
      "interpretation": "Catalogue and July announcement differ: the announcement quotes up to 21,900 MB/s write. Configuration-specific maxima, not QD1 latency or application throughput.",
      "sourceRef": "S03, S04"
    },
    {
      "component": "Micron 9650 & 6600 ION SSDs",
      "verifiedSpec": "Micron 9650 (Gen6): 28 GB/s read, 5.5M IOPS. Micron 6600 ION (Gen5 QLC): 245.76 TB usable capacity per drive",
      "interpretation": "Separates ultra-fast Gen6 TLC performance from ultra-dense 245.76 TB Gen5 QLC capacity tiers.",
      "sourceRef": "S05, S06"
    },
    {
      "component": "NVIDIA ConnectX-8 / ConnectX-9",
      "verifiedSpec": "ConnectX-8: up to 800 Gbps (PCIe Gen6 x16). ConnectX-9 SuperNIC: up to 1.6 Tbps aggregate",
      "interpretation": "Adapter/fabric capability; check per-VM and per-flow cloud entitlements separately.",
      "sourceRef": "S08"
    },
    {
      "component": "Broadcom Tomahawk 6 Switch",
      "verifiedSpec": "102.4 Tbps switching capacity per chip; production volume shipment 12 March 2026",
      "interpretation": "Datacenter fabric switch silicon enabling non-blocking 400G/800G east-west clusters.",
      "sourceRef": "S09"
    }
  ],
  "cloudMaxima": [
    {
      "capability": "High-Throughput VM Networking",
      "awsExample": "C8in up to 600 Gbps (up to 384 vCPUs)",
      "azureExample": "Esv7 up to 400 Gbps",
      "gcpExample": "C4N up to 400 Gbps (95M PPS; 50 Gbps single VPC flow)",
      "sourceRef": "S11, S17, S23"
    },
    {
      "capability": "Scale-Up Memory Instances",
      "awsExample": "U7inh-32tb: 32,768 GiB, 1,920 vCPUs, 200 Gbps",
      "azureExample": "Mdsv3 VHM: 30,400 GiB (marketed 32 TB), 185 Gbps",
      "gcpExample": "X5 (x5-2064-48t-metal): 49,152 GB (48 TB), 2,064 vCPUs, GA Sep 2026",
      "sourceRef": "S13, S19, S20, S21"
    },
    {
      "capability": "Local NVMe Capacity & IOPS",
      "awsExample": "I8g.metal-48xl up to 45 TB local storage; I8ge up to 120 TB",
      "azureExample": "Laosv5 up to 138.24 TB & 20.7M read IOPS; Edsv7 53.8 GB/s read",
      "gcpExample": "Z3 bare metal up to 72 TiB local NVMe SSD",
      "sourceRef": "S14, S15, S16, S18, S22"
    },
    {
      "capability": "Remote Block Storage Path",
      "awsExample": "R8idb: up to 300 Gbps EBS and 1.44M IOPS; io2 volume: 256k IOPS, 4,000 MiB/s, advertised average <500 µs at 16 KiB",
      "azureExample": "Esv7: 800K IOPS / 20 GB/s; Ultra Disk: 400K IOPS / 10 GB/s",
      "gcpExample": "Hyperdisk Extreme: 350K IOPS / 5,000 MiB/s; Balanced: 160K IOPS",
      "sourceRef": "S12, S17, S27, S28, S29"
    },
    {
      "capability": "Single-Flow & Inter-AZ Rules",
      "awsExample": "Ordinary single flow up to 5 Gbps; 10 Gbps cluster placement; ENA Express up to 25 Gbps. Ordinary EC2 cross-AZ: $0.02/GiB one-way payload",
      "azureExample": "Inter-AZ transfer free on documented path (peering billed separately)",
      "gcpExample": "3 Gbps external flow; 50 Gbps C4N VPC flow; $0.01/GiB sent cross-zone",
      "sourceRef": "S23, S24, S25, S34, S36, S37"
    }
  ],
  "sources": [
    {
      "id": "S01",
      "category": "hardware",
      "title": "AMD EPYC 9006 series",
      "url": "https://www.amd.com/en/products/processors/server/epyc/9006-series.html",
      "note": "vendor specifications and qualifications"
    },
    {
      "id": "S02",
      "category": "hardware",
      "title": "AMD EPYC 9006 architecture and performance white paper",
      "url": "https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/amd-epyc-9006-server-cpus-architectural-leadership.pdf",
      "note": "2026; memory-channel and peak-bandwidth discussion, platform-specific peak, not application bandwidth"
    },
    {
      "id": "S03",
      "category": "hardware",
      "title": "Samsung enterprise SSD catalogue",
      "url": "https://semiconductor.samsung.com/ssd/enterprise-ssd/",
      "note": "PM1763 catalogue maxima"
    },
    {
      "id": "S04",
      "category": "hardware",
      "title": "Samsung PM1763 mass-production announcement",
      "url": "https://news.samsung.com/global/samsung-begins-mass-production-of-pm1763-ssd-optimized-for-next-generation-ai-infrastructure",
      "note": "8 July 2026; configuration-specific announcement figures"
    },
    {
      "id": "S05",
      "category": "hardware",
      "title": "Micron 9650 product information",
      "url": "https://www.micron.com/products/storage/ssd/data-center-ssd/9650-ssd",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S06",
      "category": "hardware",
      "title": "Micron 6600 ION product information",
      "url": "https://www.micron.com/products/storage/ssd/data-center-ssd/6600-ion",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S08",
      "category": "hardware",
      "title": "NVIDIA ConnectX adapters",
      "url": "https://www.nvidia.com/en-us/networking/infiniband-adapters/",
      "note": "distinguish adapters and aggregate throughput"
    },
    {
      "id": "S09",
      "category": "hardware",
      "title": "Broadcom Tomahawk 6 production-volume release",
      "url": "https://www.broadcom.com/company/news/product-releases/64031",
      "note": "12 March 2026"
    },
    {
      "id": "S10",
      "category": "hardware",
      "title": "AWS M9g/M9gd GA announcement",
      "url": "https://aws.amazon.com/blogs/aws/now-available-amazon-ec2-m9g-and-m9gd-instances-powered-by-new-aws-graviton5-processors/",
      "note": "10 June 2026. [M9g instance specifications](https://aws.amazon.com/ec2/instance-types/m9g/) provide exact size-level limits"
    },
    {
      "id": "S11",
      "category": "hardware",
      "title": "AWS C8in/C8ib GA announcement",
      "url": "https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-ec2-c8in-c8ib-instances-ga/",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S12",
      "category": "hardware",
      "title": "AWS R8idn/R8idb announcement",
      "url": "https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ec2-r8idn-r8idb/",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S13",
      "category": "hardware",
      "title": "AWS U7i/U7inh specifications",
      "url": "https://aws.amazon.com/ec2/instance-types/u7i/",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S14",
      "category": "hardware",
      "title": "AWS I8g.metal-48xl announcement",
      "url": "https://aws.amazon.com/about-aws/whats-new/2026/02/ec2-i8g-metal-48xl-generally-available/",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S15",
      "category": "hardware",
      "title": "AWS I8ge GA announcement",
      "url": "https://aws.amazon.com/about-aws/whats-new/2025/08/amazon-ec2-i8ge-instances-generally-available/",
      "note": "29 August 2025"
    },
    {
      "id": "S16",
      "category": "hardware",
      "title": "Microsoft Laosv5 specifications",
      "url": "https://learn.microsoft.com/en-gb/azure/virtual-machines/sizes/storage-optimized/laosv5-series",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S17",
      "category": "hardware",
      "title": "Microsoft Esv7 specifications",
      "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/memory-optimized/esv7-series",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S18",
      "category": "hardware",
      "title": "Microsoft Edsv7 specifications",
      "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/memory-optimized/edsv7-series",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S19",
      "category": "hardware",
      "title": "Microsoft Mdsv3 VHM specifications",
      "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/memory-optimized/mdsv3-vhm-series",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S20",
      "category": "hardware",
      "title": "Google Compute Engine release notes",
      "url": "https://docs.cloud.google.com/compute/docs/release-notes",
      "note": "X5 GA entry dated 25 September 2026"
    },
    {
      "id": "S21",
      "category": "hardware",
      "title": "Google memory-optimized machine specifications",
      "url": "https://docs.cloud.google.com/compute/docs/memory-optimized-machines",
      "note": "X5 exact types, memory, networking, and NUMA"
    },
    {
      "id": "S22",
      "category": "hardware",
      "title": "Google expanded Z3 portfolio",
      "url": "https://cloud.google.com/blog/products/compute/expanded-z3-vm-portfolio-for-io-intensive-workloads/",
      "note": "8 July 2025"
    },
    {
      "id": "S23",
      "category": "network-storage",
      "title": "Google Compute Engine network bandwidth",
      "url": "https://docs.cloud.google.com/compute/docs/network-bandwidth",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S24",
      "category": "network-storage",
      "title": "AWS EC2 network bandwidth",
      "url": "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S25",
      "category": "network-storage",
      "title": "AWS ENA Express documentation",
      "url": "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ena-express.html",
      "note": "use this feature-specific page for current cross-AZ support and exclusions"
    },
    {
      "id": "S26",
      "category": "network-storage",
      "title": "AWS general-purpose SSD documentation",
      "url": "https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S27",
      "category": "network-storage",
      "title": "AWS provisioned-IOPS SSD documentation",
      "url": "https://docs.aws.amazon.com/ebs/latest/userguide/provisioned-iops.html",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S28",
      "category": "network-storage",
      "title": "Microsoft managed disk types",
      "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S29",
      "category": "network-storage",
      "title": "Google Hyperdisk overview",
      "url": "https://docs.cloud.google.com/compute/docs/disks/hyperdisks",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S30",
      "category": "network-storage",
      "title": "DevelopersIO original cross-AZ ENA Express experiment",
      "url": "https://dev.classmethod.jp/articles/ena-express-availability-zones-srd/",
      "note": "27 May 2026; methodology, full-RTT commands, raw statistics, and throughput"
    },
    {
      "id": "S31",
      "category": "network-storage",
      "title": "DevelopersIO original I8g/I4g fio experiment",
      "url": "https://dev.classmethod.jp/articles/amazon-ec2-i8g-instances-awsreinvent/",
      "note": "2 December 2024; 128-KiB QD1 random reads"
    },
    {
      "id": "S32",
      "category": "network-storage",
      "title": "Sirupsen napkin-math repository",
      "url": "https://github.com/sirupsen/napkin-math",
      "note": "README documents March 2026 measurement updates, environment, rounding, and S3 tests"
    },
    {
      "id": "S33",
      "category": "network-storage",
      "title": "AWS latency and distance explanation",
      "url": "https://aws.amazon.com/blogs/industries/lower-access-latency-for-your-apps-with-aws-wavelength-and-our-telco-partners/",
      "note": "25 October 2024; approximate propagation calculation"
    },
    {
      "id": "S34",
      "category": "pricing",
      "title": "AWS EC2 On-Demand pricing and transfer policy",
      "url": "https://aws.amazon.com/ec2/pricing/on-demand/",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S35",
      "category": "pricing",
      "title": "AWS managed-database transfer-cost explanation",
      "url": "https://aws.amazon.com/blogs/architecture/exploring-data-transfer-costs-for-aws-managed-databases/",
      "note": "2 November 2021; endpoint charging and service-specific exceptions. Use with current pricing, not as a standalone current tariff"
    },
    {
      "id": "S36",
      "category": "pricing",
      "title": "Google VPC/network pricing",
      "url": "https://cloud.google.com/vpc/network-pricing",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S37",
      "category": "pricing",
      "title": "Microsoft guide to Azure transfer pricing",
      "url": "https://techcommunity.microsoft.com/blog/azurenetworkingblog/a-guide-to-azure-data-transfer-pricing/4374538",
      "note": "12 February 2025; free inter-AZ transfer and separately charged networking paths"
    },
    {
      "id": "S38",
      "category": "pricing",
      "title": "AWS published EC2 Linux rate feed, N. Virginia",
      "url": "https://b0.p.awsstatic.com/pricing/2.0/meteredUnitMaps/ec2/USD/current/ec2-ondemand-without-sec-sel/US%20East%20%28N.%20Virginia%29/Linux/index.json",
      "note": "retrieved publication `2026-10-22T23:14:53Z`. Exact rate codes: m9g.8xlarge `WSZ849T6V4T9J2R4.JRTCKXETXF.6YS6EN2CT7`; m9g.48xlarge `NH4XMFJ4FQXKA4RX.JRTCKXETXF.6YS6EN2CT7`; m8g.xlarge `VQH5V8CYRKE378VY.JRTCKXETXF.6YS6EN2CT7`; i8g.48xlarge `HUMR39A9KGC9R42X.JRTCKXETXF.6YS6EN2CT7`"
    },
    {
      "id": "S39",
      "category": "pricing",
      "title": "AWS S3 regional price-list JSON",
      "url": "https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonS3/current/us-east-1/index.json",
      "note": "retrieved version `20261015173540`, publication `2026-10-15T17:35:40Z`. Storage usage types `TimedStorage-ByteHrs` and `TimedStorage-XZ-ByteHrs`; ordinary request groups `S3-API-Tier1` / `S3-API-Tier2`"
    },
    {
      "id": "S40",
      "category": "pricing",
      "title": "AWS Data Transfer regional price-list JSON",
      "url": "https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSDataTransfer/current/us-east-1/index.json",
      "note": "retrieved version `20260916132208`, publication `2026-09-16T13:22:08Z`; source `us-east-1`, destination `External`, usage type `DataTransfer-Out-Bytes`, product SKU `HQEH3ZWJVT46JHRG`"
    },
    {
      "id": "S41",
      "category": "pricing",
      "title": "AWS EBS volume types and reference rates",
      "url": "https://aws.amazon.com/ebs/volume-types/",
      "note": "includes binary-throughput footnote and provisioned-performance prices"
    },
    {
      "id": "S42",
      "category": "pricing",
      "title": "AWS EBS pricing",
      "url": "https://aws.amazon.com/ebs/pricing/",
      "note": "billing, snapshots, and regional pricing context. Generic examples on this page can use a different region's rates; do not substitute them silently for the selected reference rate"
    },
    {
      "id": "S43",
      "category": "pricing",
      "title": "AWS S3 pricing and billing units",
      "url": "https://aws.amazon.com/s3/pricing/",
      "note": "binary storage units, non-storage meters, minimums, and large-volume contact guidance"
    },
    {
      "id": "S44",
      "category": "pricing",
      "title": "AWS VPC/NAT Gateway pricing",
      "url": "https://aws.amazon.com/vpc/pricing/",
      "note": "Ohio example, processing charges, and gateway endpoint distinction"
    },
    {
      "id": "S45",
      "category": "pricing",
      "title": "AWS Billing: tier aggregation and units",
      "url": "https://docs.aws.amazon.com/en_en/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-effective.html",
      "note": "1,024 GB per TB in the transfer example; its historical example rates are not used as current rates here"
    },
    {
      "id": "S46",
      "category": "semantics",
      "title": "TrendForce Q1 DRAM outcome",
      "url": "https://www.trendforce.com/presscenter/news/20260601-13070.html",
      "note": "1 June 2026"
    },
    {
      "id": "S47",
      "category": "semantics",
      "title": "TrendForce Q2 memory forecast",
      "url": "https://www.trendforce.com/presscenter/news/20260331-12995.html",
      "note": "31 March 2026"
    },
    {
      "id": "S48",
      "category": "semantics",
      "title": "TrendForce Q3 memory forecast",
      "url": "https://www.trendforce.com/presscenter/news/20260703-13134.html",
      "note": "3 July 2026"
    },
    {
      "id": "S49",
      "category": "semantics",
      "title": "TrendForce Q4 memory forecast",
      "url": "https://www.trendforce.com/presscenter/news/20260930-13258.html",
      "note": "30 September 2026"
    },
    {
      "id": "S50",
      "category": "semantics",
      "title": "PostgreSQL 18 WAL configuration and group commit",
      "url": "https://www.postgresql.org/docs/18/wal-configuration.html",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S51",
      "category": "semantics",
      "title": "PostgreSQL standby and synchronous replication",
      "url": "https://www.postgresql.org/docs/18/warm-standby.html",
      "note": "acknowledgment and replication semantics"
    },
    {
      "id": "S52",
      "category": "semantics",
      "title": "PostgreSQL asynchronous commit",
      "url": "https://www.postgresql.org/docs/18/wal-async-commit.html",
      "note": "acknowledgment and possible recent-transaction loss"
    },
    {
      "id": "S53",
      "category": "semantics",
      "title": "AWS instance-store data lifetime",
      "url": "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-lifetime.html",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S54",
      "category": "semantics",
      "title": "AWS definition of cell-based architecture",
      "url": "https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html",
      "note": "Reference scope is documented in the linked source."
    },
    {
      "id": "S56",
      "category": "semantics",
      "title": "AWS: Timeouts, retries, and backoff with jitter",
      "url": "https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/",
      "note": "Retry amplification, deadlines, idempotency, and jitter."
    },
    {
      "id": "S57",
      "category": "semantics",
      "title": "AWS: Static stability using Availability Zones",
      "url": "https://aws.amazon.com/builders-library/static-stability-using-availability-zones/",
      "note": "Pre-provision surviving capacity; the 70% ceiling in our worked model is an assumption."
    },
    {
      "id": "S58",
      "category": "semantics",
      "title": "Amazon SQS: Available CloudWatch metrics",
      "url": "https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html",
      "note": "Backlog, in-flight work, oldest-message age, and poison-message caveats."
    },
    {
      "id": "S59",
      "category": "semantics",
      "title": "Amazon SQS: At-least-once delivery",
      "url": "https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues-at-least-once-delivery.html",
      "note": "Duplicate delivery is possible; consumers need idempotency."
    },
    {
      "id": "S60",
      "category": "semantics",
      "title": "PostgreSQL 18: Transaction isolation",
      "url": "https://www.postgresql.org/docs/18/transaction-iso.html",
      "note": "Read Committed defaults, serialization anomalies, and transaction retries."
    },
    {
      "id": "S61",
      "category": "semantics",
      "title": "RFC 9562: UUID version 7",
      "url": "https://www.rfc-editor.org/rfc/rfc9562.html#section-5.7",
      "note": "128-bit layout, 48-bit millisecond timestamp, optional counters and randomness."
    },
    {
      "id": "S62",
      "category": "semantics",
      "title": "PostgreSQL 18: UUID functions",
      "url": "https://www.postgresql.org/docs/18/functions-uuid.html",
      "note": "Native uuidv7() generation; time ordering is not commit ordering."
    },
    {
      "id": "S63",
      "category": "semantics",
      "title": "PostgreSQL 18: LIMIT and OFFSET",
      "url": "https://www.postgresql.org/docs/18/queries-limit.html",
      "note": "Skipped rows still require work; pagination needs a unique ORDER BY."
    },
    {
      "id": "S64",
      "category": "semantics",
      "title": "PostgreSQL 18: Continuous archiving and point-in-time recovery",
      "url": "https://www.postgresql.org/docs/18/continuous-archiving.html",
      "note": "Base backups and an unbroken sequence of archived WAL support recovery."
    },
    {
      "id": "S65",
      "category": "semantics",
      "title": "Amazon S3: Data consistency model",
      "url": "https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel",
      "note": "Strong object read-after-write consistency; no atomic updates across keys."
    },
    {
      "id": "S66",
      "category": "semantics",
      "title": "Amazon S3: Conditional writes",
      "url": "https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html",
      "note": "If-Match and If-None-Match check write preconditions; check operation support."
    },
    {
      "id": "S67",
      "category": "semantics",
      "title": "pgvector: Exact search, HNSW, filtering, and vector storage",
      "url": "https://github.com/pgvector/pgvector",
      "note": "Storage precision, approximate recall, graph overhead, and iterative scans."
    },
    {
      "id": "S68",
      "category": "semantics",
      "title": "vLLM: Benchmark serving metrics",
      "url": "https://docs.vllm.ai/en/latest/cli/bench/serve/",
      "note": "Time to first token, inter-token latency, throughput, and request latency."
    },
    {
      "id": "S69",
      "category": "semantics",
      "title": "Apache Kafka 4.0: Upgrade requirements",
      "url": "https://kafka.apache.org/40/getting-started/upgrade/",
      "note": "Kafka 4.0 operates in KRaft mode; ZooKeeper mode was removed."
    },
    {
      "id": "S70",
      "category": "semantics",
      "title": "PostgreSQL 18: SELECT locking clauses",
      "url": "https://www.postgresql.org/docs/18/sql-select.html#SQL-FOR-UPDATE-SHARE",
      "note": "SKIP LOCKED avoids row-lock waits but yields an inconsistent view; useful for queue-like tables."
    },
    {
      "id": "S71",
      "category": "semantics",
      "title": "Martin Kleppmann: How to do distributed locking",
      "url": "https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html",
      "note": "2016 analysis of lease expiry, stale clients, and fencing enforced by the protected resource."
    }
  ]
}