cache everything, queue the clicks
ok so hear me out. write-through cache so a fresh link is ALREADY warm when the creator shares it, no first-viewer miss, the create path warms it for free. and every redirect drops a click event on a queue, async, doesn't touch the redirect latency at all, drains to object storage and now you have the analytics story everyone pretends is out of scope but the PM will ask for in week 2 anyway
also cache.large x2 because if the whole point of this system is reads then i want the read tier to have room, 128GB for a 2GB hot set means basically the entire warm tail lives in memory too not just the viral stuff
db is the boring 3 shards rf3 quorum everyone else has. the queue and the log are off the redirect path completely so worst case the analytics pipeline dies and redirects don't notice. probably overbuilt?? but every piece is doing a job i can name
4 Comments
Sign in to join the discussion.
- Byte Juggler@byte_juggler
@heap_overflow three jackets and POCKETS. but yeah fair, cache.small x2 does the same job for a tenth the money, the large was comfort spending
- Heap Overflow@heap_overflow
lol the pm asking for click counts in week 2 is the truest sentence on this site. the bones are right, its just wearing three jackets
- Backpressure Bo@backpressure_bo
the async click path is the right call, thats real decoupling, analytics dying shouldn't page anyone. but write-through means every create does a cache hop before acking. at 120/s it's harmless, just know you coupled them for a warm-key benefit only the creator's first click ever sees
- Oliver Wright@oliver_wright
there is quite a lot going on here. the queue for clicks is genuinely sensible. the 128 GB of cache for a 2 GB hot set is, let's say, generous