Internet service in Erbil, Baghdad, and most of Iraq's major cities has improved substantially, but outages still happen — and a POS or ordering system's behavior during one is one of the most consequential things to understand before you're relying on it for a Friday night rush.
The worst-case behavior — and why it's common
Some systems, especially ones built assuming always-on connectivity, simply fail during an outage: the app freezes, an order mid-placement is lost entirely, and nobody — customer or staff — has a clear record of what was actually ordered. For a restaurant, that means either a lost sale or an argument with a confused customer.
What should actually happen instead
Orders placed or in progress during an outage should queue locally and sync automatically once the connection returns — nothing lost, just delayed. Staff-facing functions like marking a table paid or printing an existing ticket should keep working on local data even without a live connection, since none of that actually requires round-tripping to a server in real time.
What to ask a vendor directly
- What happens to an order a customer is actively placing when the connection drops mid-process?
- Can staff still view and manage already-placed orders — mark served, mark paid — without live internet?
- Is there a real answer to this, or does the vendor's demo simply never test it?
Full offline resilience is a genuinely hard engineering problem, and it's fair for a vendor to say it's on the roadmap rather than claim it's solved if it isn't — what matters is getting a straight answer either way, not a vague reassurance.