Caching

The seat map of a hot event is read 2,600 times a second during on-sale and changes 3 times a second, and until this chapter every one of those reads was 8 milliseconds of pg-primary's CPU spent recomputing an answer that had not changed. Marek puts it in Redis under seatmap:v2:8812 with a 30-second TTL, and the primary's load drops by 90 percent on the first night. Then he meets every problem the copy brings, one at a time: a buyer sees a seat as available 2 seconds after it was held; the moment the key expires, every reader misses at once and the primary goes from 10 percent to 100 in one second; a CDN with the wrong directive serves one buyer's held seats to the next; and a cached 404 hides an event for a minute after the organizer published it.

No wound from the spring on-sale closes here; the three were closed in Chapters 6, 7 and 8. What this chapter does is make the fix for the on-sale itself possible. The row lock of Chapter 6 keeps 14C from being sold twice, but only if the primary is not spending its capacity on 2,600 seat-map reads a second while the holds queue behind them. The cache is what gives the write path room, and the chapter is honest about the price: a second place a fact can live, and a list of every way the two places disagree. The network fact from Chapter 1 is here too, wearing Redis's protocol: a delete that times out may have deleted, a process can die between the commit and the invalidation, and the TTL exists because it will.

The chapter is the seat map, cached correctly, and the list of ways it was not. Two numbers decide what gets a copy; cache-aside puts the copy beside the read and keeps Postgres the only writer; the write path deletes after the commit and never sets; one reader rebuilds while the rest wait; the CDN gets 5 seconds where Redis gets 30; and the last topic is the catalogue that lets the reader name a cache bug from its shape on the dashboard.

Topics in This Chapter