$ ls articles | grep * # 26 found
Designing a URL Shortener in AWS (Part 3): Writes, Clicks, and the Slow Path
A redirect is only half the system. Part 3 follows a link from creation to its click count: validation that never fetches the destination, an idempotency key and a generated code written in one DynamoDB transaction, a Kinesis click pipeline that never slows a redirect, abuse controls for a public API with no accounts, and a test strategy that needs no cloud account.
Designing a URL Shortener in AWS (Part 2): Never Serve a Dead Link
A cache that is fast but wrong is worse than no cache. Part 2 explains the Redis record behind every redirect: three timestamps instead of one TTL, a version number on every write, tombstones that carry no destination, the narrow case in which a stale URL may still be served, and how an operator takedown propagates through DynamoDB, Redis and the edge in that order.
Designing a URL Shortener in AWS (Part 1): The Architecture
A URL shortener is a read-heavy system with one hot path: the redirect. Part 1 explains the traffic shape (100 reads for every write), why the short code comes from a leased block of integers and a keyed permutation instead of a Snowflake ID, how three cache tiers keep most clicks away from the database, and why the redirect origin is a Lambda Function URL behind Cloudflare and CloudFront rather than API Gateway.
Designing a Flash-Sale Seat Reservation System in AWS (Part 3): Holds, Payments, and the Slow Path
An admitted seat is only half a booking. Part 3 follows it through payment: a 10-minute hold, redirect signals that anyone can fake, one reconciler that makes every release decision, a payment gateway token shared across the fleet, and an SQS FIFO to DynamoDB pipeline that never makes a user wait.
Designing a Flash-Sale Seat Reservation System in AWS (Part 2): Never Sell a Seat Twice
The whole promise of the system depends on one Redis Lua script. Part 2 explains what it checks and in what order, why Lua won over MULTI/WATCH and distributed locks, and the four ways an in-memory counter can still go wrong: double rollbacks, lost replies, crashed requests, and a failover that loses the last writes.
Designing a Flash-Sale Seat Reservation System in AWS (Part 1): The Architecture
20,700 exam seats, millions of people trying at the same time, and an older system that crashed and sold seats twice. Part 1 explains what the traffic looked like, why one atomic Redis script decides who gets a seat instead of a database, how CloudFront handles three out of four requests before they reach a server, and why we added servers before the event instead of using autoscaling.
Designing a Self-Hosted AI Assistant (Part 7): Missions
A mission is Timothy's unit of long-running work: a goal driven through discover, plan, build, prove and result by a pure state machine. Part 7 covers fresh worker sessions instead of transcript replay, native and delegated CLI workers behind one contract, verification the harness owns, brakes that park instead of loop, and how schedules turn into missions and notifications.
Designing a Self-Hosted AI Assistant (Part 6): Letting the Model Act Safely
Timothy's model can run shell commands, read mail and fetch web pages, so every tool call walks a permission chain written in Go. Part 6 covers that chain, keeping big results and idle skills out of context, fencing untrusted tool output, pinning sensitive sessions to a local model, and the sandbox and network boundaries underneath.
Designing a Self-Hosted AI Assistant (Part 5): Memory and Knowledge
Timothy remembers facts about its user and searches documents the user added, and both live in one Postgres. Part 5 covers typed memories that land pending and only ever supersede, a promotion policy written in Go, three-leg recall fused with RRF into a fenced 1,500-token block, and a knowledge base the model searches through a tool instead of having it pushed into every prompt.
Designing a Self-Hosted AI Assistant (Part 4): Never Lose a Turn
A chat turn in Timothy can run for half an hour, longer than any browser tab should be trusted to stay open. Part 4 explains why a turn belongs to the session rather than the HTTP request, how a returning tab reattaches to a turn still in flight, why a session allows one turn at a time, and the five places a turn's final event was once lost.
# ---