How Arqly is built
What it is for, where the content comes from, and how it gets corrected

How Arqly is built

Most system-design material is something you read. Arqly is something you run. You draw an architecture, and a simulator traces real requests through the boxes you actually drew — not through the boxes you meant to draw.

Why it works this way

You can read a walkthrough of a URL shortener and come away certain you understand it, then freeze in an interview the moment someone asks what happens when the cache is cold. Recognition is not recall, and reading produces recognition. Every surface here is built to make you answer before you are shown anything: the workspace asks one question per stage and only reveals a suggested approach once you ask for it, and every scene makes you predict the outcome before it plays.

That is also why the simulator matters more than the diagram. A drawing cannot be wrong. A traced request can — it takes the path your edges actually describe, through the replication and quorum settings you actually configured, and reports a latency you did not choose.

What is on the site

  • 82 problems, 52 of them worked in full — product designs like a news feed or a payment system, plus the infrastructure primitives underneath them. Browse the catalog.
  • 287 interactive scenes across 23 curricula, each one building a real system — Kafka, Raft, an LSM tree, a columnar store — step by step. See the curricula.
  • A learning path that puts all 82 in one order, so no problem arrives before the concept it needs. Follow the path.

Where the content comes from

Each curriculum starts from primary sources — the original paper, the RFC, the project's own design docs and issue tracker, and the engineering write-ups from teams who ran the thing in production. Scenes cite those sources on the page, so a claim can be checked against the thing it came from rather than against us. Where a scene simplifies, it says which detail it dropped.

Nothing here carries a review score, a testimonial, or a publication date it did not earn. If a number appears, it came from a cited source or from the simulator, and the page says which.

What the simulator actually models

It is a deterministic, request-level trace engine over your graph — not a queueing simulator and not a load test. It walks the cheapest path your edges allow, charges a per-component cost, and models a node's internals (replication, quorum, failover) as real hops rather than as a replica count. The costs are editorial constants chosen to be realistic; they are not measurements of your system, and the page that explains every one of them is public.

What the simulator models, and what it doesn't

When we get it wrong

Distributed systems are full of details that are true of one version, one configuration, or one vendor and not of the next, and some of what is on this site will be wrong. Every scene carries a flag icon: use it for a factual error, a misleading diagram, a typo, or a citation we missed. Accepted reports are published with what we changed and why, so a page never quietly reads differently than it did last month.

Read the errata log

Using it without an account

Everything works signed out. Your work saves to your own browser first and only syncs to a server if you sign in, which exists so your attempts follow you between devices — not as a gate. No part of the curriculum is behind one.