diagramanything
v0 · 2026 EN·
atlas · archive · generator

A living atlas of one-screen explanations.

Browse the growing diagram library, then ask for a new figure when the atlas does not have your topic yet.

>

017 diagrams indexed · generated SVGs can be previewed and downloaded.

Generate SVG Download Embed-ready

Recent diagrams

five of seventeen
№ 01

The harness around a coding agent

AI · systems
MODEL claude · gpt · gemini CONTEXT CLAUDE.md · readme · docs project conventions TOOLS read · edit · grep · run bash · web_fetch VERIFIER tests · linter · types "did it actually work?" MEMORY past chats · skills user preferences OUTPUT code · PR · message → user-visible artifact USER prompt · feedback · review verify ⟲ harness · n. — the structure that makes a model useful

A model alone is a curious oracle. A model in a harness is a worker. The interesting craft of 2025–2026 has been less about better models and more about the satellites: context shaping what the model knows, tools shaping what it can do, verifiers closing the loop on whether it succeeded. The dashed line is the most important — most agents that fail in production fail there.

№ 02

How a request reaches a static site on Cloudflare Pages

networking · web
browser cloudflare DNS CF edge (anycast) pages router asset bucket A example.com? → 104.21.x.x GET / · TLS handshake · Host: example.com match host → pages X internal RPC: which deployment? fetch /index.html 200 OK · <html>… (cached at edge for next visitor) ~5ms +30ms +1ms +5ms note: every box-to-box hop after the edge is intra-Cloudflare. user-perceived latency is dominated by the first three steps.

From the browser's point of view, a static site loads "instantly." Almost all the work — DNS lookup, TLS, edge routing — happens before the bytes even start. Once Cloudflare's edge has matched the host to a Pages project, the rest is internal traffic between Cloudflare's own services. The closer the user is to a Cloudflare PoP, the more this whole diagram collapses into "just a few milliseconds."

№ 03

OAuth 2.0 with PKCE — the dance, plainly

auth · web
USER CLIENT (your app) AUTH SERVER click "log in with X" generate verifier SHA256 → challenge redirect: /authorize?challenge=...&client_id=... login page · "do you allow this app to read X?" enter password · approve scopes redirect: ?code=ONE_TIME_CODE POST /token (code + verifier) SHA(verifier) == stored challenge? access_token + refresh_token "you're logged in" PKCE = Proof Key for Code Exchange. The verifier never leaves the client; the challenge can be public. Stops a stolen authorization code from being usable.

Vanilla OAuth 2.0 worried about server-to-server secrets. PKCE (pronounced "pixy") was added because mobile and SPA apps can't keep a secret. The trick: the client invents a random verifier, sends only its SHA-256 hash to the auth server up front, and reveals the verifier itself only when redeeming the code. Even if an attacker intercepts the authorization code, they don't have the original verifier and can't redeem it.

№ 04

A Merkle proof — belonging to a set, without the set

crypto · data structures
merkle proof · n. — showing one block belongs to a set without revealing the rest you compute given to you ROOT HASH H( H_AB + H_CD ) H(AB) H( H(A)+H(B) ) H(CD) H( H(C)+H(D) ) H(A) H(B) H(C) H(D) block A …bytes block B …bytes block C the one you have block D …bytes to prove C is in the set you hash C, then need only H(D) and H(AB) — two hashes, not the whole tree — to rebuild the root and compare.

A Merkle tree hashes data in pairs, all the way up to a single root hash that fingerprints the entire set. The quiet magic is the proof: to convince someone that block C belongs, you don't hand over the whole set — you hand over your block plus the handful of sibling hashes along the path to the root (here just H(D) and H(AB)). They recompute the root and check it matches. This is what lets Git, Bitcoin, and Certificate Transparency verify membership in enormous sets with a logarithmic-sized proof — a perfect diagram subject because the whole idea is a shape: a path climbing a tree.

№ 05

Consistent hashing — serving a key without knowing the whole cluster

distributed systems
consistent hashing · n. — add or remove a server and only ≈K/N keys need to move hash space 0 ···················· 2³²−1 ↻ clockwise Server A h(A) = 0x1A3F… Server B h(B) = 0x5D8A… Server C h(C) = 0x9FE2… key:session:7 key:item:42 key:user:99 server key owner used in: redis cluster · cassandra · dynamodb · memcached · cdn routing. virtual nodes improve balance by placing each server at multiple ring positions.

In modular hashing, a key's server is determined by hash(key) mod N — clean until N changes and every assignment shuffles. Consistent hashing fixes this by projecting both keys and servers onto a shared circular hash space. A key's owner is whichever server appears first clockwise from the key's position. When a server joins or leaves, only the keys in that server's arc of the ring need to migrate — roughly K/N out of K total, the rest stay put. That bounded migration cost is why Redis Cluster, Cassandra, DynamoDB, and most CDN routing tables use it: the cluster can reshape itself without emptying and refilling every shard.