Drafts
Not publicly listed yet — edit one to publish it.
- Blog Building a Real-Time Ad Bidder in Rust — Part 4: Under Load Circuit breakers, hedged reads, and bounded queues — then the load tests that judged them, including the cache fix that made one stage 112x faster.
/blog/rtb-bidder-part-4-under-load/Publish → - Blog Building a Real-Time Ad Bidder in Rust — Part 3: Serving an ML Model in 4 Milliseconds In-process ONNX inference, a boot-time parity check against training/serving skew, atomic hot-reload, and safe rollout with cascades and A/B routing.
/blog/rtb-bidder-part-3-ml-serving/Publish → - Blog Building a Real-Time Ad Bidder in Rust — Part 2: Where the Money Moves Budget pacing, frequency-cap semantics, first-price auctions, and why the win notice is a fraud surface that has to be cryptographically signed.
/blog/rtb-bidder-part-2-money/Publish → - Blog Capacity Estimation Drills: From Product Sentence to Server Count Part 4 of the napkin-math series — full worked capacity drills: a messaging app and a market-data platform taken from one-sentence descriptions to QPS, bandwidth, storage, server counts, and the shard verdict, plus an interactive drill machine to practice on.
/blog/capacity-estimation-drills/Publish → - Blog Database Sizing for System Design: Indexes, Replicas, and When to Shard Part 3 of the napkin-math series — why indexes speed reads by slowing writes, how caches and replicas scale the read path, what the working set means for RAM, and the four-check decision for when sharding is actually justified.
/blog/database-sizing-for-system-design/Publish → - Blog Delivered Twice — the Idempotent Consumer At-least-once delivery means every consumer will eventually see the same message twice. The inbox pattern — the outbox's mirror image — makes the second copy harmless.
/blog/idempotent-consumer/Publish → - Blog Building a Real-Time Ad Bidder in Rust — Part 1: Designing the 50ms Hot Path Latency budgets as enforced contracts, a nine-stage pipeline, bitmap indices that survive 100K campaigns, and Redis key design as a performance lever.
/blog/rtb-bidder-part-1-hot-path/Publish → - Blog Agent Memory: How LLM Agents Remember and Forget LLMs forget everything between calls, so memory is something we engineer around the model: a write path, a read path, a forgetting policy, and a nightly consolidation job — plus the honest numbers on when a plain long context beats all of it.
/blog/agent-memory/Publish → - Blog Change Data Capture — the Database Already Wrote It Down Every database keeps a crash-recovery journal of every change it commits. CDC taps that journal and turns your commits into events — no polling, no second write, no dual-write problem.
/blog/change-data-capture/Publish → - Blog Event Sourcing — the Ledger Is the Truth Store every change as an event and derive current state by replaying them. The dual-write problem disappears by construction — and you get an audit trail and time travel for free.
/blog/event-sourcing/Publish → - Blog LLM Evals: How to Test LLM Apps and Agents Why 'looks good to me' fails as QA for LLM apps, and the eval harness that replaces it: golden sets, code graders before LLM judges, judge calibration, and the reliability math that separates demos from products.
/blog/llm-evals/Publish → - Blog The Dual-Write Problem — Two Writes, No Safety Net The most common reliability bug in event-driven systems: save the fact to your database, announce it to everyone else — and discover there is no transaction that covers both.
/blog/dual-write-problem/Publish → - Blog What SVG Animation Can Actually Do A tour of animating diagrams without reaching for a GIF — attributes, motion paths, line drawing, sequencing, easing, and a systems diagram that explains itself while you watch.
/blog/svg-animation-tour/Publish → - Blog The Transactional Outbox — a Sticky Note the Crash Can't Kill The standard fix for the dual-write problem: store the event as a row in your own database, in the same transaction as the data — and let a relentless relay deliver it.
/blog/transactional-outbox/Publish →