Your bar software has to work when the internet does not

Every festival has the same story. The site fills up, thirty thousand phones saturate the local cells, the 4G router behind the bar drops to nothing, and something stops working. If that something is your bar, you have a very expensive problem for the rest of the evening.

This is not an edge case. It is the normal condition of an event site at peak, and it is the reason a drinks machine has to be designed offline-first rather than cloud-first.

What “offline-first” actually means

The phrase gets used loosely. Concretely, it means the machine holds everything it needs to serve a drink locally:

• Recipes and pump mapping stored on the machine, not fetched
• Prices resolved locally
• The guest interface served from the machine itself, not from a CDN
• Stock levels tracked locally and reconciled later
• Payment balances, for cashless setups, readable and debitable without a round trip - the hardest of the five, and the one we do not currently do

The cloud gets the data afterwards. It is a destination for what happened, not a dependency for what is happening.

The test is simple: unplug the internet mid-service and see whether the next guest gets a drink. If the answer is no, the system is cloud-dependent no matter what the marketing says.

Where cloud-dependent designs break

The failure modes are worth naming because they are not obvious until you see them:

The tablet is a thin client. If the guest interface is hosted remotely, a connectivity drop turns your kiosk into an error page. Serving it from the machine on the local network removes an entire class of failure.

Licence checks phone home. This one bites at the worst moment. If the software validates its licence against a server on every start, a network outage plus a restart equals a machine that refuses to work. Cocktail-O-Matic handles this with a configurable grace period - seven days by default - during which everything keeps running normally without connectivity. The licensing model is designed so a network problem is never a service problem.

Payment requires authorisation. This is the one dependency that is genuinely hard to remove, and it is worth being straight about our own position: NFC cashless in Cocktail-O-Matic keeps the wallet in the cloud, so the debit is a network call. Drinks keep pouring without connectivity, but that payment path does not. A local balance that reconciles later is the design that removes the dependency entirely, at the cost of a harder double-spend problem across bars. If your site has unreliable connectivity, plan a dedicated link to the bars rather than assuming the payment step will degrade gracefully.

Time comes from the network. Machines without a battery-backed clock get their time from NTP. Boot one with no network and it may think it is 1970, which quietly breaks anything time-based - session expiry, event windows, ordering of records.

The reconciliation problem

Working offline is the easy half. The hard half is what happens when connectivity returns and two sources of truth have both moved.

The rules that keep this sane:

• The machine wins for anything it observed. It poured the drink; it knows. The cloud did not.
• Queue events, do not overwrite state. Send “poured 40 ml gin at 21:04” rather than “stock is now 1.2 litres”. Events merge; state snapshots clobber each other.
• Make every event idempotent. A retry after a timeout must not double-count a sale. Give each event an id generated on the machine and deduplicate on arrival.
• Expect clock skew. Two machines whose clocks differ by a minute will produce a reconciled timeline that is subtly out of order. Record both the machine’s time and the server’s receipt time.

Get this wrong and the symptom is not a crash, it is analytics that quietly disagree with the till. That is worse, because you may believe them for months.

What you legitimately lose offline

Being honest about the trade: while a machine is disconnected, you do lose things.

• Live fleet monitoring - you cannot see the machine’s state from the cloud portal until it reconnects
• Cross-machine stock views on a multi-bar site
• Remote configuration changes
• Real-time revenue figures

None of those stop drinks being served, which is the point. The design goal is not “no degradation”, it is “no degradation of the thing the guest is standing in front of you for”.

Questions to ask any vendor

If you are evaluating drinks automation, these four questions separate offline-first from cloud-first quickly:

1. If the internet drops mid-service, what stops working?
2. If the machine reboots while offline, does it still serve?
3. How long can it run disconnected before anything degrades?
4. When it reconnects, how do you avoid double-counting sales?

A vendor with a real answer to all four has thought about event sites. A vendor who has to check has not.

Why this matters beyond festivals

It is easy to file this under “festival problem”, but the same design pays off in a permanent venue. Routers fail. ISPs have outages. Someone unplugs the wrong thing during a refit. A bar whose ability to serve depends on a working internet connection has added a dependency it never had before automation - and the whole promise of automating was to make service more reliable, not less.