techdiagrams.net

Architecture templates.

50 real system designs composed from named distributed-systems patterns. Every one opens in the editor as a live, editable diagram — components, connections, pattern badges, zones and all.

Product backends 10

AT-LEAST-ONCE INSIDE — EXACTLY-ONCE IS THE CLIENT'S DEDUPmsg · client-id 8812persist BEFORE ackenqueue deliverywhere is Bob?push over socketheartbeatsno socket → notifyAlicesends: client msg-id 8812Gateway A1M held socketsPresenceonline · typing · last-seenChat Servicepersist FIRST, then ackMessage Storeconversation-shardedDelivery Queueper-recipient · at-least-onceConnection Registrybob → gateway BDelivery Workerscompeting consumersGateway Bholds Bob's socketBobdedupes by msg-idAPNs / FCMoffline fallbackthe reliability chain:1. persisted before Alice sees ✓2. redelivery allowed end-to-end3. Bob renders msg-id 8812 once, however many times it arrives

Chat that never loses a message

WhatsApp-shaped messaging: a connection registry finds the recipient's gateway, delivery is at-least-once with client-side dedup, and offline users fall back to push.

11 components · 10 connections · 5 patterns
ONE BLAST RADIUS — EVERYTHING AT-LEAST-ONCE INSIDEPOST /checkout · Idempotency-Keyorder + outbox, one txnpoll new eventspublish OrderPlacedconsumechargereserve stockafter N failuresPaymentFailed → releaseStorefrontweb + mobileCheckout APIidempotency-key dedupeOrders DBorders + outbox tableOutbox Relaypolls outbox → publishesOrderPlacedat-least-oncePayment Servicesaga step · compensablePSP / Gatewayexternal — Stripe/AdyenInventoryreserve → release on failureDead letterspoison events → humanswhy no double charge:1. retry hits the same Idempotency-Key → same response2. outbox means the event exists iff the order exists3. consumer dedupes on event id before charging

Checkout that never double-charges

An e-commerce checkout composing idempotency keys, a transactional outbox and a compensating saga so retries can never charge twice.

9 components · 9 connections · 5 patterns
THE ONLY WRITERS — SIZED FOR THE DB, NOT THE CROWDpage loadsbuy clicks onlyadmitted · 429 + retry-after past budgetstock readsbuy → queueddecrement shard hash(user)%16write orderpre-warm T-301M ShoppersT-0: everyone at onceEdge / CDNproduct page cachedRate Limitertoken bucket per userSale APIfast paths onlyStock Cachepre-warmed · shard-keyedCache WarmerT-30min: preloadBuy Attemptsleveled · at-least-onceOrder Workersconsume at DB paceStock Counters ×16sharded — no hot keyOrders DBnever meets the crowdthe survival ordering:cache absorbs reads → buckets meter intents →queue absorbs writes → shards absorb contention.the database never notices the sale

Flash-sale survival kit

1M shoppers, 10k units: edge caching and token buckets tame the flood, sharded counters kill the hot key, and a leveled queue means the database never meets the crowd.

10 components · 9 connections · 5 patterns
GEO-PARTITIONED DISPATCH CELLSplace orderwrite orderOrderPlaced→ kitchen prepscatter offers · first-accept winsoffer ×5driver assignedCustomer Apporder + live trackingAPI Gatewayauth · rate limitsOrder Servicevalidates · pricesOrders DBgeo-partitioned by cityOrderPlacedat-least-once · leveledDispatch Orchestratorauction per orderDriver Gatewayoffer push · GPS inDrivers — Cell 8a2downtown · 214 onlineDrivers — Cell 8b7suburbs · 61 onlineRestaurant Servicekitchen display · prep timesCustomer Notifystatus: driver assignedthe auction gather:offer 5 nearest drivers, 8s deadline —first accept wins, others revoked.no accepts → widen radius, re-scatter

Food delivery platform

An event-driven delivery backend: orders absorb spikes through a leveling queue, and driver dispatch runs as a scatter-gather auction over geo-partitioned cells.

11 components · 10 connections · 5 patterns
THE LINE — PRIORITY MEANS OTPS NEVER WAITOrderShippedcampaignexpand + filtertransactionaldigest @ 9am localseen? skipadapters · per-channel breakerspoison → parkOrder ServiceOrderShippedCampaign Tool2M-user blastNotify APIintents inRouterexpand · prefs · quiet hoursPreferenceschannels · quiet hours · localesPriority Queuetransactional firstScheduled Queuedigests · quiet-hours holdsDedup Windowevent+user · 24h TTLSendersprovider adaptersDead Lettersafter 5 attemptsEmailSES / ResendSMSTwilioPushAPNs / FCMwhy a priority queue, not two services:one pipeline = one dedup window, onepreference model, one audit trail —priority is a queue property, not a fork

Notification service

One pipeline for every notification: recipient-list expansion with preferences, priority queues so OTPs beat campaigns, delayed digests, a dedup window and a DLQ.

13 components · 13 connections · 5 patterns
FRESHNESS PIPELINE — THE MATCH IS ONLY AS GOOD AS THISrequest ridek-nearest in cell 8a2really available?×1.4 multiplieroffer to driveroffer ⇄ acceptGPS pingsupdate cellswindowed demand/supplyheartbeatsRider Apprequest rideRider Gatewayheld connectionSurge Pricerdemand/supply per cellMatch Servicek-nearest in cellGeo IndexH3 cells · driver positionsPresenceheartbeats · availabilityLocation StreamGPS pings · 40k/sLocation Workerscompeting consumers ×12Driver Gatewayoffers out · GPS inDriver Appaccept / declinewhy competing consumers:40k pings/s, any worker may take any ping —add workers to scale, lose one andnothing is waiting on it

Ride-hailing dispatch

Real-time rider–driver matching: GPS pings stream through competing consumers into a geospatial index, presence tracks who's really online, and surge pricing closes the loop.

10 components · 12 connections · 5 patterns
WRITE PATH — FAN-OUT-ON-WRITEREAD PATH — MERGE AT READGET /feedhot pathprecomputed (normal authors)pull celebrities at read timePOST /postappend ×N followersfollowers of authormentionsPost Servicewrites go herePostCreatedat-least-onceFanout Workersskip authors > 10k followersTimelinesper-user · materializedReaderopens the appFeed APIread + write edgeFeed Buildermerge write-path + read-pathFeed Cachehot feeds · early expiryNotificationsmentions · DMsPosts Storecelebrity posts read hereSocial Graphwho follows whomthe hybrid rule:followers < 10k → write-time fanoutfollowers ≥ 10k → read-time pullone knob, both failure modes avoided

Social news feed

The hybrid feed: fan-out-on-write materializes timelines for normal users, celebrities are merged at read time, and a stampede-protected cache keeps hot feeds cheap.

11 components · 11 connections · 5 patterns
CONSISTENCY CORE — ONE WRITER PER SEATstampede inadmit 200/shold 14B · lease+tokenchargecommit with token — stale holds rejectedpayment failed → release holdreap expiredconfirmed → ticket20k Fanson-sale at 10:00Waiting Roomadmits 200/s · fair orderBooking APIhold → pay → confirmHold Reaperexpired leases → back on saleSeat Holdslease 120s + fencing tokenSeat Inventorysource of truthPSPcharge within the leaseTicket DeliveryPDF + wallet passwhy fencing tokens:a browser that froze during paymentwakes with an EXPIRED hold — its commitcarries an old token and is refused.the seat already belongs to someone else

Ticket booking with seat holds

On-sale day without oversells: a waiting room levels the stampede, seats are held with leases plus fencing tokens, and payment failure releases the hold via saga compensation.

8 components · 8 connections · 5 patterns
READ PATH — MICROSECONDS, CACHE-SHAPEDGET /x7Ab9edge miss onlylookupmiss → shard readclick eventPOST /shortennext idwrite slugVisitorGET /x7Ab9CDN Edge302s cached · 80% never reach usRedirect Service300µs budgetSlug Cacheslug→url · 404s cached tooSlug Storehash(slug) → shardCreatorshorten a long URLCreate Servicemint + writeID Generatorsnowflake: time|node|seqClick Streamfire-and-forgetAnalyticscounts · referrers · geowhy negative caching matters:without it, every random slug a bot triesis a guaranteed cache miss AND a DB read —the attack costs you more than the attacker

URL shortener at scale

The interview classic, production-grade: k-sorted Snowflake IDs, hash-sharded storage, cache-aside reads with negative caching, and 302s served from the CDN edge.

10 components · 9 connections · 5 patterns
PIPES & FILTERS — EVERY STAGE RESTARTABLEresumable uploadnew master → jobsfan-out renditionsfan-in: wait-for-allpublishpull-throughHLS segmentsfailover on health scoreCreatoruploads 4K masterUpload Serviceresumable chunksMasters Bucketraw originalsTranscode Orchestratorjob graph per title1080p EncoderH.264/HEVC720p / 480p Encoderladder renditionsAudio + CaptionsAAC · WebVTTPackagerwaits for ALL renditionsOriginsegments + manifestsCDN — provider Aprimary · 92% hitCDN — provider Bfailover · warmVieweradaptive bitrate playerwhy fan-in waits for all:a manifest referencing a missing renditionis a player error in the wild — ship thetitle late, never broken

Video streaming pipeline

Upload → transcode fan-out across renditions → fan-in packaging → origin → multi-CDN delivery with health-scored failover.

12 components · 14 connections · 5 patterns

Data platforms 8

DERIVED VIEWS — ALL REBUILDABLEtxn: rows + outboxWALcheck schemachange eventsupsert docsevict keysappend factspoisonOrder Servicewrites rows + outboxOLTP PostgresWAL = changelogCDC Connectortails WAL · logical decodingSchema Registrycompatibility gateChange Streamper-table topics · keyed by PKSearch Indexrebuilt from streamCache Invalidationevict on changeStreaming ETL → Warehousetransform in-flightDead Lettersunparseable changeswhy CDC beats dual-writes: the app writes ONCE(its own database). everything downstream derivesfrom the WAL — which can't disagree with the data,because it IS the data.

CDC replication backbone

Log-based change data capture streams every row change out of the OLTP database — feeding search, caches and the warehouse without touching app code.

9 components · 8 connections · 5 patterns
eventsappendby userby itemsession featurestrending nowuser features · p99 5mshot keyspersonalized feedApps + WebSDK · batched eventsCollectorvalidate · enrich · geoClickstreamkeyed by userSessionizersession windows · 30min gapTrending (top-K)count-min sketch · per categoryFeature Storeonline + offlineRecs APIassemble, don't computeFeature Cachehot users · 60s TTLrequest-time rule: the recs API reads precomputedstate — it never aggregates. every millisecond ofcompute was spent BEFORE the user asked.

Clickstream personalization

Behavioral events flow through session windows into a feature store and top-K sketches — recommendations served in milliseconds from state computed in-stream.

8 components · 9 connections · 5 patterns
READ MODEL — DISPOSABLE, REBUILDABLEWRITE MODEL — BORING ON PURPOSEqueryfan-outgather top-200top-20, re-rankedwritesCDCchangesupsert · idempotentShoppertypes 'red running shoes'Search APIscatter-gather coordinatorShard 1terms a–hShard 2terms i–qShard 3terms r–zRe-rankerML · top-200 → top-20Catalog Servicethe write sideCatalog DBsource of truthChange StreamCDC → index upsertsIndexeranalyze · tokenize · upserthedging: if a shard hasn't answered by p95,fire a backup request to its replica and takethe first response. tail latency, tamed.

E-commerce search platform

CQRS split: the catalog writes to Postgres, CDC feeds the inverted index, and queries fan out to shards with hedging and an ML re-rank stage.

10 components · 10 connections · 5 patterns
DOMAIN-OWNED — DATA STAYS HOMEmetric querycompiled SQLresolve productspushdown: filter+projectpushdownpartition-pruned scanAnalystone SQL, three domainsSemantic Layermetric definitionsFederated Engineplanner · pushdownCatalog & Lineagediscovery · ownershiporders productowner: commerce teamcustomers productowner: CRM teamevents productowner: platform teammesh is an org-chart pattern wearing anarchitecture costume: it works exactly as wellas domain teams actually own their products.

Federated data mesh

Domains own their data as products; a federated query engine joins across them with pushdown; a semantic layer gives everyone one metric vocabulary.

7 components · 6 connections · 5 patterns
ANALYTICS SIDE — ZERO LOAD ON THE PRIMARYorderstxnsreplicationchange deltasincremental applyread viewsad-hoc scans · bounded stalenessCustomerstransactionsOrder ServiceOLTP writesPrimary (row store)point reads/writesAnalytics Replicacolumnar · seconds behindView Maintainerapplies deltas to viewsMaterialized Viewsrevenue/min · funnel stepsExec Dashboardssub-second loadsIVM in one line: revenue_per_min += delta,not SELECT SUM() over everything, every refresh.freshness gets cheap when updates are incremental.

HTAP live dashboards

Dashboards read a columnar analytics replica kept fresh by replication and incremental view maintenance — the OLTP primary never sees a GROUP BY.

7 components · 7 connections · 4 patterns
SPEED LAYER — FRESH, APPROXIMATE, DISPOSABLEBATCH LAYER — SLOW, EXACT, AUTHORITATIVEeventsstreamarchive allapprox aggregatesfull scanrecompute · overwritefresh sliceexact historymerged answerEvent Sourcesapps · services · CDCEvent Logfan-out to both layersSpeed Layerstreaming · approximateReal-time Viewlast few hoursBronze — rawimmutable archiveBatch Layernightly full recomputeGold Tablessilver → gold · exactServing Layermerge: gold + real-timeBI / Analystsone query surfacethe lambda trade: two codebases to maintain,in exchange for exactness AND freshness.kappa is what you get when you refuse the trade.

Lambda architecture warehouse

A batch layer for accuracy and a speed layer for freshness, merged at query time — with a medallion lake underneath.

9 components · 9 connections · 4 patterns
metrics · 2M pts/sadmitted seriesconsumedigestsage outdownsampled tiersrecenthistoryevaluate rulesService Fleet500 pods · SDK metricsIngest Funnelvalidate · budget · shedMetrics Streampartitioned by seriesSketch Aggregatort-digest · HLL · countersHot TSDBraw · 24h retentionRollup Jobs1s→1m→1h downsamplingCold Tier13 months · object storeQuery APIhot + cold mergeAlertingSLO burn ratesthe two observability killers, both handled at ingest:· cardinality budget (labels × values is your real bill)· sketches over raw (percentiles that merge correctly)

Metrics & observability platform

A telemetry funnel with cardinality budgets, sketch-based aggregation (t-digest, HLL), hot/cold storage tiers and rollups — observability that doesn't bankrupt you.

9 components · 9 connections · 5 patterns
THE ONLY PIPELINE — NO BATCH TWIN TO DRIFTeventsappendconsume · offset-trackedwindow aggregatestoo late for windowqueryREPLAY from offset 0 (new version)Product Appsweb · mobile · backendEvent Gatewayvalidate + stamp event-timeEvent Logretained 30d · partitionedStreaming Jobwindows + watermarksLate-Event Parkingafter watermark → side outputServing Storeupsert by (window, key)Live Dashboardsp95, funnels, countskappa's bet: one codebase, reprocessing by replay.the cost: the log must retain enough history,and the sink must be idempotent — or replaysdouble-count everything.

Real-time analytics (Kappa architecture)

One stream, one processor, one serving store — the log is the source of truth, and reprocessing is just replaying it from offset zero.

7 components · 7 connections · 5 patterns

Distributed-systems classics 6

THE CHAIN — WRITE PATH IS THE REPLICATION PATHwritepropagatepropagate → commitack (HWM advances)strong readCRAQ: read if cleanepoch 7 · chain configWriterput(object)Readerget(object)HEADaccepts writesMIDDLEpropagates · serves clean readsTAILcommit point · strong readsChain mastermembership · epoch++ on failuresegmented log per node: appends land in theactive segment; everything below the low-watermark is truncated after snapshot — cheap GC.

Chain-replicated object store

Writes flow head → middle → tail, strong reads come from the tail, and CRAQ lets clean replicas serve reads — with high/low water marks tracking commit progress.

6 components · 7 connections · 5 patterns
CONSISTENT COREacquire → lease + token 33heartbeat renew /5sacquire — queuedraft replicatewrite (token 33) ✓write (token 32) ✗ FENCEDWorker Aholds lease · token 33Worker Bqueued — waitingWorker A′ (GC-paused)stale · token 32Lock service (leader)lease 10s · mints tokensLock replicas ×2raft followersProtected resourceaccepts token ≥ 33the rule: a distributed lock is only assafe as the resource's token check.Lock + lease + fencing — all three,or you have a suggestion, not a lock.

Distributed lock service with fencing

Leases, heartbeats and fencing tokens over a consistent core — including the exact scenario where a GC-paused client gets fenced instead of corrupting data.

6 components · 6 connections · 5 patterns
REPLICA SET FOR KEY K · RF=3 ON THE RINGput(k,v) · W=2replicatereplicatereplicate ✗store hint for Creplay when C returnsMerkle anti-entropyClientput(k,v) · get(k)Coordinatorany node · ring lookupReplica Aack ✓Replica Back ✓Replica CDOWNNode D — hint storehint: (C, k=v)quorum math: W=2 + R=2 > RF=3 →every read overlaps every write.A+B ack, so the client gets successwith C dead — no failover, no leader.vector clocks: concurrent puts createsiblings the client must reconcile —Dynamo detects conflicts, it doesn'tinvent a winner (LWW would).

Dynamo-style key-value store

A leaderless replicated KV store composing consistent hashing, quorum writes, hinted handoff, read-repair and Merkle anti-entropy — the Cassandra/Riak blueprint.

6 components · 7 connections · 6 patterns
US-EASTEU-WESTAP-SOUTHwrite · ~5msasync repl · version vectorsasync replasync repl · ~180ms RTTApp — USwrites locallyLeader — USaccepts writesApp — EUwrites locallyLeader — EUaccepts writesApp — APACwrites locallyLeader — APACaccepts writesHAZARD — last-writer-wins: with clock skew, a write thathappened LATER by wall-clock can be silently discarded.Use version vectors + application merge for anything youcan't afford to lose (carts, counters, documents → CRDTs).

Global multi-leader database

Three regions, each accepting local writes, meshed with async replication — version vectors detect conflicts and the LWW hazard is spelled out on the canvas.

6 components · 6 connections · 5 patterns
CONSISTENT CORE — 5-NODE RAFT · SURVIVES 2 FAILURESPUT /config · lease 10sAppendEntries · heartbeatcatching upwatch push: /config changedService Awrites config · holds leaseService Bwatches /config/*Node 1LEADER · term 12Node 2followerNode 3followerNode 4followerNode 5follower · lagginglease: Service A must heartbeat or itskeys vanish — a crashed servicederegisters itself by silence.commit = majority (3/5): Node 5lagging never blocks a write.

Raft-backed config store (etcd-style)

A five-node Raft consistent core serving linearizable configuration with leases and watch notifications — the etcd/Consul architecture under Kubernetes.

7 components · 6 connections · 5 patterns
SHARD FLEET — RANGES OF THE KEYSPACESELECT / INSERTresolve rangesscatterscatter → gathercross-shard write · 2PCrange split · filtered backfillApplicationplain SQL — no shard awarenessQuery router (vtgate)plan · route · gatherTopology serviceshard map · consistent coreShard [-80)primary + replicasShard [80-c0)primary + replicasShard [c0-)HOT · splitting…Shard [c0-e0) — newbackfillingdesign rule: model queries so 95%+ hit ONEshard (shard by tenant/user). scatter-gatherand 2PC exist — as exceptions, priced in.

Sharded SQL (Vitess-style)

A query router fans SQL across range shards via a topology service — with scatter-gather reads, 2PC for cross-shard writes, and a live range split in progress.

7 components · 6 connections · 5 patterns

Collaboration & sync 3

PER-DOCUMENT AUTHORITY — OPS IN, ORDER OUTop: insert('h',pos4)route by doc idbroadcast merged ops + cursorsappendcompact periodicallyEditor Atypes 'hello' at pos 4Editor Btypes concurrently at pos 4WS Gatewayconnection registry · sticky by docDoc session (CRDT)RGA sequence CRDT · merges opsOp logappend-only · the truthSnapshot compactorops → snapshot · truncatewhy CRDT beats locks here: both editors insert atpos 4 simultaneously — the CRDT gives both a stableidentity, so A and B converge to the SAME textwithout anyone waiting or losing a keystroke.

Collaborative document editor

Google-Docs-style co-editing: sequence CRDTs merge concurrent keystrokes, an op-log is the source of truth, and snapshots keep join time flat.

6 components · 6 connections · 5 patterns
PER-FILE AUTHORITY + DURABILITYdeltas + cursor @60Hzsubscribemux by filebroadcast merged deltas + presenceappend → compactfetch assetsDesigner Adrags rect #7Designer Brecolors rect #7Viewerread-only · cursors visibleConnection gatewaysticky by file idFile session (actor)delta-CRDT map · authorityChangelogdeltas · compactedAsset CDNimages · fonts · exportswhy both edits win: A moved rect #7, B recolored it —different properties of the same object are independentCRDT registers. True conflict (both move it) = LWW perproperty, which is fine for geometry.

Multiplayer canvas (Figma-style)

Live design-tool multiplayer: delta-CRDT maps per file, a session actor as ordering authority, 60Hz cursor presence, and a compacted changelog.

7 components · 7 connections · 5 patterns
THE DEVICE — FULLY FUNCTIONAL OFFLINEread/write · ~2mspush outbox deltasapply · version checkCDCchanges since cursorpull deltas → mergewake: new changesMobile appoptimistic UILocal store (SQLite)primary · outbox of pending opsSync APIdelta exchange · cursorizedServer DBauthoritative · version per rowChange feedrow versions in commit orderPush notifiersilent sync nudgeconflict path: both sides edited row 42 →sync returns theirs+ours with versions →the CLIENT merges (domain rules: lateststatus wins, notes concatenate) → push again.

Offline-first mobile sync

A mobile app that works on the subway: local store as primary, delta sync with cursors, optimistic UI, and conflicts resolved at the client.

6 components · 7 connections · 5 patterns

Fintech 6

PII BOUNDARY — RAW DATA NEVER LEAVESpurpose allowed?tokenize PIIencrypt under user keystore tokensprivileged op → 2nd humanproposal + approvalevery action, hash-chaineddestroy key = crypto-shredverify chain integrityBusiness Servicesthe whole app tierConsent Storepurpose × user grantsMaker-Checkerfour-eyes approvalsToken VaultPII ⇄ tokenPer-User Keysone key per userApp Datatokens only — no raw PIIAudit Loghash-chained · append-onlyErasure ServiceGDPR art. 17 executorAuditor / DPOverifies the chaincrypto-shredding: backups are immutable, so you can'tdelete a user from last month's tape. But if their dataonly ever existed under their key — burn the key andevery copy everywhere becomes noise.

Audit & privacy for a regulated platform

Tamper-evident audit logging, maker-checker approvals, tokenized PII with per-user keys, and right-to-erasure implemented as crypto-shredding.

9 components · 9 connections · 5 patterns
CELL 1 — ONE ISSUER GROUP'S WHOLE WORLDCELL 2 — IDENTICAL, SHARES NOTHINGauth request · t=0route ≤5ms · issuer→cell 1limits lookup ≤5msmiss → hedged read ≤20msscore ≤30msother issuersCard NetworkISO 8583 · 100ms SLACell Routershuffle-sharded · statelessAuth Servicecell 1 · decision in ≤40msNear-cache L1+L2hit ratio 99.4%Account Store3 replicasRisk Scorer≤30ms or default-allow rulesAuth Servicecell 2 — identical, isolatedNear-cachecell-localAccount Storecell-localthe budget: route 5 + cache 5 + risk 30 + decision 10+ network 20 = 70ms, 30ms headroom.Every edge label is a line item — spend deliberately.

Card authorization in under 100ms

A latency-budgeted authorization path: cell-based isolation with shuffle sharding, near-caches for account state, and hedged reads — every hop annotated with its share of the 100ms.

9 components · 8 connections · 5 patterns
SOURCE OF TRUTH — EVERYTHING ELSE IS PROJECTIONtransfer · Idempotency-Keypost(debit A, credit B)append postingemit committed postingsupdate viewGET balance — reads the view, never the journalassert books balanceWallet Apptransfer £20 to AshaWallet APIidempotency-key dedupeLedger Serviceposts double entriesJournalappend-only · immutablePostingCommittedat-least-onceBalance Projectorfolds postings → balancesBalances Viewrebuildable projectionTrial Balancenightly: Σdebits = Σcreditswhy money can't vanish:1. debit + credit commit in ONE posting2. balances derive from postings — no drift3. retry replays the same posting id → no-op

Digital wallet on a double-entry ledger

A wallet where every balance is a materialized view over an append-only double-entry journal — money moves effectively-once, and the books always balance.

8 components · 8 connections · 5 patterns
THE BOOKS — MUST AGREE WITH THE PSP'S BOOKScharge · Idempotency-Keyrecord transition firstauthorize / capturesigned eventsapply: captured / failedpost on settlepull daily reportcomparedispute.createdreverse postingOrder Servicewants: charge £49Payment Orchestratorstate machine ownerPayment Stateone row per attemptPSPexternal — Stripe/AdyenWebhook Receiververify signature · dedupeInternal Ledgerdouble-entry postingsSettlement FilesPSP daily reportsReconciliationledger vs PSP · dailyChargeback Handlerdispute → compensationrule of PSP integrations: the HTTP response is an opinion,the webhook is a rumor, the settlement file is the truth.Design for all three to disagree.

Payment gateway integration done right

Authorize → capture → settle as an explicit state machine, with idempotent PSP calls, signed webhooks, daily reconciliation and chargebacks as compensating transactions.

9 components · 10 connections · 5 patterns
eventsfeaturesscore requestvelocity features ≤10msscore ≤50msmirrored — result logged, ignoreddeadline miss → rules decideconfidence 0.4–0.7labeled outcomestraining data for v43Transaction Streamevery card swipeWindow Aggregatorsliding 5m / 1h / 24hFeature Storeonline + offline parityFraud Scorerdecision ≤80msChampion Modelv41 — decidesChallengerv42 — shadow onlyRules Fallbackdeterministic · always answersReview Queuegray-zone scoresAnalystslabel & decideCase DBlabels → retrainingthe loop: challenger shadows today's traffic,analysts label the gray zone, both feed the nextchampion — the model improves without everbeing trusted blindly.

Real-time fraud detection pipeline

Streaming velocity features, a champion model with a shadow challenger, a rules fallback for model timeouts, and a human review queue for the gray zone.

10 components · 11 connections · 5 patterns
new order / canceldrainseq #184,224,001…append eventsreplaypublishfanoutTrading ClientsFIX / binary gatewaysOrder Gatewayvalidate · rate-capRing Bufferlock-free · boundedSequencerstamps total orderMatching Enginesingle-threaded state machineEvent Journalappend-onlyWarm Replicareplays → identical bookMarket Datatrades · quotes · depthSubscribersmarket data feedswhy single-threaded wins here: the engine does no I/Oand holds no locks — it just folds ordered events.Determinism turns disaster recovery into `replay`.

Trading venue order book

A deterministic matching engine behind a lock-free ring buffer and a sequencer — event-sourced so that replaying the journal rebuilds the exact book, tick for tick.

9 components · 8 connections · 5 patterns

Resilience & scale 7

THE DANGEROUS DEPENDENCY — POOLED AND FUSEDPOST /order · 1s budgetdeadline: 800ms leftisolated poolcharge · 500ms capread cataloghedge at p95on failure: serve staleMobile app1s total budgetEdge Gatewaystamps deadline: 800msOrders APIretry budget: 10%/sPayments client poolbulkhead · 20 threads maxPSP / Gatewayflaky third partyCatalog replica Aprimary read pathCatalog replica Bhedge targetFallback cachelast-good responsesthe deadline ladder:client 1000ms → gateway 800ms → PSP call 500ms.Every inner timeout is SHORTER than its caller's —reverse that and you build zombie work.read the badges: every edge declares its armor.An unlabeled remote call is an unmanaged risk.

Anatomy of a safe RPC

One call path wearing every stability pattern: timeout, retry budget, circuit breaker, bulkhead, hedged reads, graceful fallback and deadline propagation.

8 components · 7 connections · 6 patterns
CELL 1 — TENANTS SHUFFLED HERECELL 2CELL 3request · tenant idtenant → cell lookuprouting table updatesTenantsA → ZCell Routerthin · cached routing tableAPIcell 1DBcell 1 · isolatedAPIcell 2DBcell 2 · isolatedAPIcell 3DBcell 3 · isolatedControl planecreates cells · migrates tenantsshuffle sharding: each tenant is assigned 2 of 3 cells.A poison tenant hurts only its shuffle-set —most tenant pairs don't even share one cell.

Cell-based architecture

Tenants shuffle-sharded into self-contained cells behind a thin router — a bad deploy or poison tenant takes out one cell, never the fleet.

9 components · 8 connections · 5 patterns
PRIMARYPILOT LIGHT · RTO HOURS · RPO MINUTESWARM STANDBY · RTO MINUTESHOT STANDBY · RTO SECONDSwritesasync replicationasyncsemi-syncProduction appfull capacityPrimary DBsource of truthApp (not running)AMIs + IaC readyReplicaasync · minutes behindApp (10% capacity)always on · scales on failoverReplicaasync · seconds behindApp (full capacity)takes traffic in secondsReplicasemi-sync · near-zero losscost grows left → right; downtime shrinks the same way.Pick the cheapest tier whose RTO/RPO the businesscan actually sign — then DRILL it. An unrehearsedfailover is a second outage.

Disaster recovery tiers

Pilot light, warm standby and hot standby side by side — the same application at three price points of RTO and RPO.

8 components · 7 connections · 5 patterns
REGION A — US-EAST · FULLY SELF-SUFFICIENTREGION B — EU-WEST · FULLY SELF-SUFFICIENTclosest regionregion-local onlyregion-local onlyasync replicationasync replicationmembership · quorumGlobal DNS / anycastlatency-based routingGatewayus-eastAppserves tenants homed A-MDB (region A)owner of A-M writesGatewayeu-westAppserves tenants homed N-ZDB (region B)owner of N-Z writesReplication hubasync · ordered per tenantWitness regionquorum tiebreaker · no data planethe golden rule: region B failing must not addone millisecond to region A. If a request crossesregions synchronously, you built one regionwith extra steps.

Multi-region active-active SaaS

Two live regions with homed tenants, strict regional isolation on the request path, hub-and-spoke event replication and a witness region for honest failover.

9 components · 9 connections · 5 patterns
THE SAME BUILD, EARNING TRUST IN STAGESrequests95%5% + mirror of bluewave 0: deploy here firstwave 1 after bakegolden signalspromote / rollback weightsfeatures released independentlyUsersunaware, ideallyTraffic managerweighted routingCI / CDmerge → build → wave 0Blue — v41 (live)95% of trafficGreen — v42 (canary)5% + mirrored trafficOne-box regionwave 0 · bakes 24hCanary analysisauto promote / rollbackFeature flagsrelease ≠ deploy · kill switchmirrored traffic is the cheat code: green processesreal production requests whose responses are thrownaway — bugs surface before a single user is exposed.

Progressive delivery

Blue-green, canary analysis, a one-box region and feature flags composed into a release path where a bad deploy is a non-event.

8 components · 8 connections · 5 patterns
THE OLD WORLD — BEING STRANGLEDTHE NEW WORLD — EARNING TRUST ROUTE BY ROUTE100% of trafficunmigrated routesorders routes · 20% and risingneeds legacy customer datatranslated legacy callscopy historyverified rowsTrafficunchanged clientsRouting facadeper-route: 80% old · 20% newLegacy monolithshrinking · frozen featuresLegacy DBstill authoritative (for now)Anti-corruption layerlegacy model → clean modelNew Orders serviceclean domain · new stackBackfill + verifycopy history · diff · reportNew DBauthoritative after cutoverdark reads: for migrated routes the facade can queryBOTH sides, serve the old answer, and log any diff.Cutover happens when the diff rate is zero for a week —confidence measured, not assumed.

Strangler-fig migration

Escaping a monolith without a big-bang rewrite: a routing facade shifts traffic route by route while an anti-corruption layer and backfill keep both worlds consistent.

8 components · 9 connections · 5 patterns
CASCADING FAILURE DOMAIN — SPREADING LEFT3s timeout · retry ×3 · no jitterwaves, not a streamall keys miss at onceherd: 10k misses together30s inner vs 3s outerstill working for dead callers10k clientsretry ×3 · no jitterLoad balancerhealthy — and helplessAPItimeout: 30s (!)CacheTTL expired at :00Databaseconnections exhaustedService Bunbounded queue · growingfour mistakes, one outage:1. no jitter → retries arrive as synchronized waves2. inner timeout > outer → zombie work fills every thread3. shared TTL → cache stampede at the worst moment4. no retry budget → load ×4 exactly when capacity is lowestthe fix is the 'Anatomy of a safe RPC' template:jittered backoff · timeout ladder · retry budgets ·stampede protection · load shedding.

The retry storm (anti-pattern)

What NOT to build: synchronized retries, an inner timeout longer than the caller's, a shared cache TTL and no jitter — watch one slow database become a full cascade.

6 components · 6 connections · 5 patterns

Platform & infra 5

GraphQL — one queryREST · Idempotency-Keybatched resolversone query for N idsaggregatededupe writesdomain eventssigned webhookAPI Consumerspartners + appsREST Gatewayaggregation · rate limitsGraphQL Federationone graph, many subgraphsDataLoader Layerbatch + dedupe per requestOrders APIsubgraph + RESTUsers APIsubgraph + RESTIdempotency Storekey → response, TTL 24hWebhook Dispatchersigned · retried · dead-letteredPartner Endpointtheir infrastructure, their bugspick ONE composition style per clientclass — running both for the sameclients doubles every schema changewebhook contract:HMAC signature + timestamp window(replay protection), retries withbackoff, DLQ + manual replay

API platform — composition, idempotency & webhooks

The two API composition styles (gateway aggregation vs GraphQL federation) side by side, with DataLoader batching against N+1, idempotency keys on writes, and signed webhooks with retry.

9 components · 10 connections · 5 patterns
ACTIVITIES — EVERY SIDE EFFECT LIVES HEREstart(orderId)append + replayschedule activitiesfires as history eventcancel orderexhausted retries → unwindrelease reservationOrder APIstarts workflowsFulfillment Workflowdeterministic · replayableEvent Historyappend-only, the truthDurable Timerwait 24h for pickupTask Queuesactivity dispatch · affinitySignalscancel / address changeReserve Inventoryactivity · retry ×3Charge Paymentactivity · idempotentBook Shippingactivity · retry ×5Notify Customeractivity · best effortCompensationsrefund · release · cancelthe workflow function is DETERMINISTIC:crash anywhere → replay the history →resume mid-flow as if nothing happenedhistory grows per event — long-livedworkflows roll over with continue-as-new,carrying state into a fresh run

Durable workflow — order fulfillment

A Temporal-style durable workflow orchestrating fulfillment: deterministic workflow code, activities with retry policies, durable timers, cancel signals and saga compensation.

11 components · 11 connections · 6 patterns
KUBERNETES CLUSTER — MESH-INJECTED, GITOPS-MANAGEDHTTPSroutegRPC via sidecarcache-asideregister + healthscale replicasmerged manifestsapply — reconcile loopClientsweb + mobileIngress GatewayTLS · auth · routingBFF / Aggregatorclient-shaped APIService Discoveryregistry + healthOrders Servicemesh sidecar injectedCatalog Servicemesh sidecar injectedUsers Servicemesh sidecar injectedOrders DBstateful set + PVCCatalog Cacheread-heavy reliefHPA / Metricsscale on RED signalsGit Repothe desired stateGitOps Controllerreconciles cluster ← repothe sidecar does the boring hard parts:mTLS, retries, outlier ejection — a podthat fails health checks silently leavesthe load-balancing poolGitOps rule: kubectl is read-only forhumans — every change is a commit,every rollback is a revert

Kubernetes microservices reference

A production-shaped Kubernetes stack: gateway + BFF at the edge, mesh sidecars between services, HPA autoscaling, service discovery with outlier ejection, and a GitOps loop as the only write path.

12 components · 11 connections · 6 patterns
POOLED CELL — DENSE, CHEAP, RLS-ENFORCEDSILO CELL — DATABASE-PER-TENANTrequests + tenant JWTquota checktier: pooledtier: siloWHERE tenant_id = ? (+ RLS)access logTenants A–xxxthousands, pooled tierEnterprise tenantcontractual isolationAPI Edgeauthn · tenant contextPer-tenant Quotasfair-share throttlingTenant Routerdirectory: tenant → cellApp — pooled cellmulti-tenant workersApp — silo celldedicated workersPooled DBshared tables + RLSTenant DBdatabase-per-tenantAccess Auditwho touched whattiering is economics: pooled = margin,silo = the enterprise deal. the routerdirectory lets one product run both

Multi-tenant SaaS data plane

Tenant routing into two isolation tiers — pooled shared-table with row-level security for the many, database-per-tenant silos for the few — with per-tenant quotas keeping neighbors quiet.

10 components · 9 connections · 5 patterns
CHOREOGRAPHY — FUNCTIONS REACT, NOBODY OWNS THE FLOWORCHESTRATION — THE STATE MACHINE OWNS THE FLOWPOST → 202 AcceptedOrderReceivedpoll GET /status/:idrule: source=checkoutValidated eventkeep warmrule: needs sagainvokeinvokewrite progressafter N failuresClient Appfire and pollAPI Gatewayreturns 202 + request idEvent Bridgecontent-based routingWarmerprovisioned concurrencyValidate Fnreacts to OrderReceivedEnrich Fnreacts to ValidatedStep Orchestratorstate machine owns the flowReserve Fnstep 1 · retry policyCharge Fnstep 2 · idempotentStatus Storerequest id → progressDLQ + destinationsfailures, parkedchoreography scales teams;orchestration scales understanding —choose per flow, not per company202 + status endpoint = async request-reply: no held connections, no gatewaytimeouts, retries stay client-side

Serverless event-driven backbone

An event bridge routing to two styles side by side — choreographed functions reacting to events, and a step-function orchestrator owning a flow — with async request-reply and DLQ routing.

11 components · 11 connections · 5 patterns

AI systems 4

THE ACTION BOUNDARY — NOTHING ACTS WITHOUT PASSING HEREgoal + budgetplan ⇄ re-plandispatch stepsdrafts for reviewapprove / revise (max 1 round)tool callsirreversible? pauseguarded execution · compensableevery step tracedUser goal“fix the failing invoices”Orchestratorowns goal · budget · deadlinePlannerdecomposes into stepsWorker agents ×None step eachCritic / judgeDIFFERENT vendor · reviews draftsHuman checkpointapproves irreversible actionsTool routerschema guardrails · allow-listExternal systemsside effects live hereRun logevery step · replayablecompensation, saga-style: if step 4 of 5 fails,the tool router replays steps 1-3's registeredundo actions. Agents don't get to leave a mess.the run log makes agents debuggable: replay anytrajectory deterministically, diff two runs, andfeed failures back into evals.

Agentic AI platform

An agent system with adult supervision: planner and workers, a cross-model critic, guard-railed tool calls, human checkpoints for irreversible actions and deterministic replay.

9 components · 9 connections · 7 patterns
MODEL FLEET — SIZED BY THE ROUTER, NOT BY HOPEpromptwithin budgetprefix hit? skip prefilleasy 80% · also the fallbackhard 20%batched decodehedge at p95Product teamsevery AI feature in the orgLLM GatewayauthN · quotas · budget governorModel routercheap-first cascadePrefix / KV cacheshared system promptsSmall modelfast · handles ~80%Continuous batcherin-flight batching · GPU-saturatingFrontier model — replica Athe expensive 20%Frontier model — replica Bhedge targetthe cascade is the cost model:small model $0.10/M handles 80%,frontier $10/M handles 20% —blended cost drops ~7× vs frontier-only.

LLM serving gateway

One gateway for all model traffic: cheap-first routing cascade, fallback models, hedged requests, prefix/KV caching, continuous batching and a hard budget governor.

8 components · 7 connections · 6 patterns
TRAINING WORLD — OFFLINE, POINT-IN-TIME CORRECTSERVING WORLD — ONLINE, MILLISECONDSbackfill featurespoint-in-time training setscandidate v13 + lineagepromote championdeploy challengersame definitions, syncedonline features <10mspredictmirror requestsprediction statsdrift → retrainRaw eventsclicks · transactions · labelsFeature store — offlinepoint-in-time correctTraining pipelinescheduled + drift-triggeredModel registryversions · lineage · approvalsFeature store — onlinesame definitions · <10msDrift monitorinputs + predictions watchedServing — champion v12100% of answersChallenger v13 — shadowmirrored traffic · answers discardedProductasks for predictionstraining-serving skew is THE silent killer:one feature definition, materialized twice,beats two teams' “identical” implementationsevery single time.

MLOps: training to serving

The full ML loop: one feature store feeding both training and serving, a model registry with lineage, champion-challenger shadow serving and drift-triggered retraining.

9 components · 11 connections · 5 patterns
INGESTION & RETRIEVAL — WHERE RAG QUALITY ACTUALLY LIVESingestembeddings upserttermschanged docs onlyquestionsemantic lookup firstdense top-50 · ACL filtersparse top-50candidatesfuse (RRF)top-8 + promptDocs · wikis · ticketsthe knowledgeChunk & embedsplit → embed → upsertVector indexdense · HNSWKeyword indexsparse · BM25Freshness loopre-embeds changed docs onlyUserasks in proseRAG APIauth → retrieve → generateSemantic cachesimilar-question hitsRe-rankercross-encoder · top-50 → top-8LLManswers WITH citationsthe model is the LAST box for a reason:bad retrieval + great model = confident nonsense.Great retrieval + decent model = cited answers.

Production RAG platform

Retrieval-augmented generation beyond the demo: hybrid dense+sparse retrieval, a re-rank stage, ACL-aware filtering, a semantic cache and freshness re-indexing.

10 components · 11 connections · 6 patterns

Edge & IoT 1

FACTORY SITE — SURVIVES WAN LOSSCLOUD — ASSUMES DEVICES ARE OFFLINEModbus / BLEMQTT · QoS 1telemetry topicsadmittedappendreported statemerge reportset desireddesired state writedelta on reconnectSensor Fleet10k devices · sleepyEdge GatewayModbus/BLE → MQTTMQTT BrokerQoS 1 · persistent sessionsIngestion Funnelvalidate · dedup · budgetTelemetry Streamkeyed by deviceTelemetry Storedownsampled tiersTwin Servicedesired ⇄ reportedTwin Storeper-device JSON docsControl APIfleet ops · rolloutsOperatorsets firmware v2 targetcommands are not RPCs here: the operator writesDESIRED state, the device reports ACTUAL state,and reconciliation happens whenever the devicewakes up — minutes or days later.

IoT fleet telemetry & control

Thousands of intermittently-connected devices: an edge gateway translates protocols, MQTT absorbs bursts with backpressure, and device twins make commands survive offline gaps.

10 components · 10 connections · 5 patterns