You mention resources calculated on-read and combat writes batched. When a fleet crosses from DO1 to DO2 and triggers combat, how are you handling that consistency boundary? Colocating everything into the target DO, or something else?
Also, actual alarm drift in prod with concurrent fleet arrivals? And client reconciliation when the countdown hits zero but the alarm hasn't fired?
durable objects: Most important is the Ocean logic for me. The source Island immedtiatley dispatches ships (fire and forget) and registers the fleet in the Ocean. When the alarm is triggered, the battle takes place within this single DO context: the defender's state is read and the results are written back. in parallel arrivals on the same island are serialized.
no cross DO transactions are happening. the problem won't be (yet) that fleet arrivals will be just miliseconds apart.
with alarm drifts: i havent observes that beahiuvor yet three is a drift check performed every 100 alarm cylces with self correction if necessary.
on the client sync part: countdown runs on the epoch by the server. hits zero, waits a sec for buffer, hard-reloads. if the alarm hasn't fired yet, next alarm cycle (shortly after) resolves it. safety net: any fleet 5+ minutes overdue gets cross-checked, with exponential backoff retry on failed return deliveries. no websocket push on this one as mentioned earlier.... the reload is the reconciliation.
Also, actual alarm drift in prod with concurrent fleet arrivals? And client reconciliation when the countdown hits zero but the alarm hasn't fired?
Clean aesthetic.