Read capacity is shards × copies, that's the whole problem

Strip the theming and this problem is one sentence: you have a 60k/s read fan-in, a 1 second staleness ceiling that makes TTL caching nearly useless, and therefore your database replicas ARE your read tier. Size them like it.

What the edge can and can't do. A quarter of every seat-map response is static venue geometry, and that quarter is immutable, so cdn.pop x2 serves it from the PoP with a clear conscience. The availability overlay is the other 75% and it must not be cached beyond 1s, so 45k/s of misses land on origin. No amount of cache cleverness changes that number; the contract forbids it. This is the anti-URL-shortener.

The read math. 5 shards of db.large at RF 3: reads are served by any live copy, so capacity is 5 x 3 x 8k = 120k/s against the 45k stream (rho 0.375 read-side). People think RF 3 is a durability tax. Here it's doing double duty as read throughput, which is why quorum acks are non-negotiable: the copies serving your reads have to actually agree about which seats exist.

The write math. Holds are contested CAS writes, 3k/s at the flash peak plus 600 bookings. Write capacity is per-shard primaries: 5 x 1.6k = 8k/s, rho 0.45. Losing any single copy leaves 2 of 3 for quorum on every shard, so the stampede rides through a node failure.

App tier fronts only the 48.6k miss stream (7x xlarge, rho 0.87). $13.50/hr all in. The interesting failures on this problem are all consistency failures wearing capacity costumes.