vyson.Join waitlist

Batch statusCurrent batch is fullNext cohort starts 15 Nov 2026Join the waitlist →Current batch is fullNext cohort starts 15 Nov 2026Join the waitlist →Current batch is fullNext cohort starts 15 Nov 2026Join the waitlist →Current batch is fullNext cohort starts 15 Nov 2026Join the waitlist →Current batch is fullNext cohort starts 15 Nov 2026Join the waitlist →Current batch is fullNext cohort starts 15 Nov 2026Join the waitlist →Current batch is fullNext cohort starts 15 Nov 2026Join the waitlist →Current batch is fullNext cohort starts 15 Nov 2026Join the waitlist →

Backend latency game

The Latency Game.

Can you tell 50 microseconds from 5 minutes? Most developers are off by 100× on at least one of these.

7 real backend operations. From a Postgres index lookup to inserting a million rows.
Slide to guess how long each takes. The scale jumps 10× at every step, from microseconds to minutes.
Score up to 100 per question for being in the right order of magnitude. See the real number and why it’s that fast or slow.

Spoilers Latency numbers every backend engineer should know

Operation	Typical	Range	Why
Insert 1 million rows into Postgres, one INSERT per row, each committed separately. App and Postgres on the same machine, default settings, NVMe SSD.	≈ 5 min	2 min – 20 min	Every row is its own transaction, and every commit waits for the disk. In one transaction it takes ~15 s. With COPY, ~1–2 s. Same rows, about 200× faster.
Postgres fetches 1 row by primary key from a 1M-row table. Warm cache, timed inside Postgres (EXPLAIN ANALYZE), network excluded.	≈ 50 µs	20 µs – 100 µs	A few hops through an index that’s already in memory. When your API is slow, it’s rarely this lookup. It’s the round trip and the code around it.
Same 1M-row table, but you filter on a column with no index, so Postgres reads every row. Warm cache, timed inside Postgres, a narrow table.	≈ 100 ms	30 ms – 200 ms	About 2,000× slower than the primary-key lookup, from one missing index. At 50 requests a second, this query alone keeps 5 CPU cores busy.
Your app server runs GET user:42 on Redis. How long until your code has the value? Same AWS availability zone, existing connection, small value.	≈ 300 µs	100 µs – 600 µs	Redis does the work in about 1 µs. The rest is the network round trip. 50 GETs in a loop cost ~15 ms; one MGET costs ~0.3 ms.
Send one message to Kafka with acks=all and wait until it’s confirmed. 3 brokers across 3 availability zones, all in-sync replicas must confirm.	≈ 5 ms	2 ms – 20 ms	Durability means copying the message to other zones before Kafka says yes. Batching (linger.ms) costs a little latency per message and buys a lot of throughput.
Fetch a 1 KB object from S3. How long until the first byte arrives? GetObject from an EC2 server in the same region.	≈ 30 ms	10 ms – 100 ms	About 100× a Redis GET. S3 is built for durability and throughput, not small fast reads. Keep it out of hot request paths, or put a cache in front.
Your users are in India, your servers are in AWS us-east-1 (Virginia). One network round trip from Mumbai and back? AWS network between ap-south-1 and us-east-1.	≈ 190 ms	170 ms – 230 ms	Light in fibre is fast, but the cable route is long. A new HTTPS connection needs 2–3 round trips, so that’s ~0.5 s before the first byte. Region choice is an architecture decision.