Homo sapiens by birth;

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.