Deep-dive developer posts on scaling, system design, OS internals, AI, and the edge cases that break production — every post ships with real, working code.
Start reading →SELECT * FROM orders
ORDER BY created_at DESC
LIMIT 50 OFFSET 250000;from: OFFSET 1000000: Why Your Pagination Falls Over at Page 10,000
Page 2 of the order list loads instantly. Page 5,000 takes 8 seconds. Same query, same index — OFFSET makes Postgres scan and discard everything before the page you asked for. Cursor-based pagination fixes it for good.
Kubernetes rolls out a new deploy, sends SIGTERM, and gives your pod 30 seconds before SIGKILL. If your server doesn't drain in-flight requests in that window, every customer mid-checkout during a deploy gets a dropped connection.
A hands-on review of Claude Code's subagent/Task tool after a week of real feature work with it — where delegating to a fresh-context agent genuinely pays off, where it just adds a round trip, and the failure mode worth knowing before you lean on it.
Order B's event timestamp is earlier than order A's, even though A happened first on a different server. The servers' clocks drifted 400ms apart. Here's why wall-clock time can't order events across machines, and how Hybrid Logical Clocks fix it.
Running 3 instances of a cron worker means the nightly report runs 3 times. You don't need ZooKeeper or etcd to fix that — a lease row in the database you already have gets you correct leader election in about 30 lines.
The order list page loads fine with 5 orders in dev and falls over with 10,000 in production. Here's the ORM lazy-loading trap that causes it, how to see it in the query log, and the two real fixes: eager loading and batching.
