Nothing guarantees your database is reachable, or even online, but that won’t stop others from trying to update it. How well does your system respond once it’s recovered, and what happens to all those offline updates?
In your concert app, a new event is added and organizers are tracking down sponsors. Once a deal is struck, the sponsor (and their agreement) is plugged into your database, although sometimes the network is down, and the updates need to be sent several times before they’re deemed successful.
You land your first sponsor and send the agreement off to your database, but the network’s down again. Not a big deal, it’s saved on your computer, and the system will periodically retry. For now, they just asked for their company logo on the concert page.
15 minutes later, the sponsor calls back, asking if they can put a banner at the event instead. Sure, what’s the harm. You plug it into your database, and this time, the network is back online.
We know the order of these updates, since we watched them unfold: first, it was a page logo, then it changed to a banner.
But sadly, your database doesn’t have that advantage. After sending off the banner request, suppose our old request finally comes through, overwriting the more recent data. That’s bad.
Since you can’t depend on electricity, servers, wifi, phone batteries, or cell service always being available, the updates you send should describe their own order, ensuring your database always knows which values to keep.
That’s why gun attaches time to each update. While computer time is almost never accurate, it’s often good enough for approximating.
Regardless of order, we can know which updates to keep, simply by comparing update time stamps.
Now, as easy as all this sounds, there’s more nuance. What happens if an update is applied with a timestamp two years in the future, does it prevent other writes from being acknowledged?
