Take the log, delete the cron job: decay ranking in one indexed column

Ranking needs order, not values. The decay here is multiplicative and shared: in log space, advancing the clock subtracts the same number from every row at once ^[5][6]. A uniform translation of a column cannot change which entry is on top. What a timer would be doing, a million times a tick, is moving every row by an identical amount and then discovering nothing changed places ^[3].

That symmetry is the load-bearing assumption, not a convenience. The term you throw away is -k*t, and it is common to all rows only because k is common to all rows ^[6]. Give tiles individual half-lives and it becomes -k_i*t, which varies per row, and an index on ln(P) + k_i*t_P quietly returns the wrong order with no query error to tell you ^[18].

The constants check out. At a three-day half-life, k = ln2/3 = 0.2310 per day ^[2][14], and the seconds-domain figure quoted in the post, 2.674e-6, times 86,400 is that same 0.231 ^[9][15]. The twenty-year number needs a footnote: at 0.231 per day the key gains about 84 a year, so 1687 is twenty years measured from the epoch, not twenty years past a present value of 55, which itself puts the epoch roughly 238 days back ^[10][19]. Either reading is far outside a double's exponent range anyway, which is the author's point about never calling exp on rank_key directly ^[10].

Display still needs a number, and that is where the discipline shows up. You exponentiate only after shifting the domain to now, and the author reports the shifted value sitting in the 6 to 10 range in log terms ^[10], which is a heat of about 400 to 22,000 ^[17]. Additions stay in log space too, using a log1p-based log-add so a small payment landing on top of a large one does not round away ^[8].

The second half of the writeup is less tidy and worth more. Having removed the scheduled job, the author still had to build a lock by hand ^[13]. All 1,000 tiles live in one Cloudflare Durable Object, which gives a single JS execution stack with one thing running at a time ^[11], and that reads like free mutual exclusion. It is not. Every await is a yield point, and the input gate only holds delivery across storage operations, not across a D1 query or an outbound fetch ^[12]. A SELECT that checks for existing locks lets two callers both see zero locks and both proceed ^[12]. The fix is to do the check and stake the claim in a block containing no await at all, against a plain in-memory Set, where the single thread genuinely guarantees no interruption ^[13].

Both halves come from the same accounting. State that changes on its own has to be recomputed, and state that changes only when money moves does not. The algebra pushes the decay into a constant so nothing has to run; the in-memory Set pulls the claim out of the database so nothing has to be trusted across a yield. Neither one was bought with more infrastructure.