One clock, no server: how the deal timer stays identical everywhere
The lightning deals count down in sync on every device, and there is no backend to sync them. The trick is that nothing is stored at all.
The lightning deals on the front page count down. When the timer hits zero, a new set of dishes drops. Open the site on your phone and your laptop at the same moment and you will see the same dishes, at the same discounts, with the same seconds remaining. There is no server doing that. There is no database of deals. There is, in fact, nothing stored anywhere.
The usual way, and why we skipped it
Normally a feature like this needs a backend. Someone picks the deals, writes them to a table with a start and end time, and every client asks the server what is live right now. That works, and it also means running a server, keeping it awake, and having a place where a mistake can make two visitors see different things.
We did not want any of that. This site has no backend by design, so the deals had to be derivable rather than stored. Which turned out to be a much nicer property than a compromise.
Deriving instead of storing
The whole schedule is a pure function of the clock. Take the current time in milliseconds, take it modulo the length of one full cycle, and you know exactly which drop is live and how far into it you are. Feed that drop number into a seeded pseudo-random generator and you get the dish selection and the discount percentages.
Both halves matter:
- The clock is shared. Every device already agrees roughly what time it is, so nobody needs to be told which drop is current โ they can each work it out.
- The randomness is seeded. Our generator takes a string and returns the same number every time, so drop 47 always produces exactly the same ten dishes at exactly the same discounts, on every machine, forever.
That combination gives you something that looks live and behaves live without a single network request. The countdown is not fetched. It is computed, sixty times a second, from a number your device already has.
The parts that were fiddly
Two things were harder than expected.
The first was hydration. A server-rendered page and the browser that takes it over have to agree on the markup, and a countdown is by definition different a second later. The fix is that no clock is read during render. The component starts in a neutral state, and the time is only sampled after the page is alive in the browser, so the first paint always matches.
The second was rhythm. Our first version gave every drop the same duration, and it felt like a metronome โ pleasant for about a minute, then oddly mechanical. Now each drop gets its own length, somewhere between one minute and ninety seconds, derived from the same seeded generator. It is still perfectly deterministic, but it no longer ticks like a machine, and the next drop arrives slightly before or after you brace for it.
What the honesty costs us
Real lightning deals in real apps are often not lightning at all. The timer resets, the discount is priced in, and the urgency is decoration. Ours is fake in a much more literal way: nothing is being sold, so the discount is fake, the saving is fake, and the pressure is a joke you are in on.
What we did not want to do is make it fake in a sneaky way. Because the schedule is derived from the clock, it genuinely cannot be personalised. There is no version where the timer runs faster because you hesitated, or where a dish gets cheaper because you looked at it twice. Everyone on the site right now is looking at exactly the same countdown, and nobody โ including us โ can lean on it.
A small argument for deriving things
Most of this site works the same way. The plate colours behind each dish come from the dish id. The ratings come from the dish id. Which courier turns up comes from the order. None of it is stored, which means none of it can drift, none of it needs a migration, and none of it requires knowing anything about you.
It is a constraint that started as laziness about infrastructure and ended up as the thing that makes the whole simulation feel solid. If the same input always gives the same output, the world stays consistent โ even when the world is made of nothing.