Engineering Velo Dine: Building a Sync-First POS Ecosystem

The Problem With Legacy POS Systems

When you walk into a busy cafe, the point-of-sale (POS) system is the heartbeat of the operation. If it slows down, the entire restaurant slows down. Most legacy POS systems were built as monolithic desktop applications. They worked fine when a cashier was the only one punching in orders. But modern restaurants don't work that way anymore.

Today, a single table might have orders coming from a waiter's tablet (Captain's App), the customer's own phone (QR Portal), and the main billing counter — all simultaneously. Legacy systems handle this by polling the database every few seconds, which leads to race conditions, double-booked inventory, and missed kitchen tickets.

The Velo Dine Architecture: Sync-First via WebSockets

When we engineered Velo Dine, we threw out the polling model entirely. Instead, we built the entire ecosystem around a real-time WebSocket architecture powered by Node.js and Redis Pub/Sub.

Here's how it works in practice: When a customer scans a QR code and adds a cappuccino to their cart, that action doesn't just write to a database. It publishes an event to a Redis channel dedicated to that specific restaurant location. Every connected client — the Captain's Android app, the Windows billing terminal, and the Kitchen Display System (KDS) — is subscribed to that channel.

Within 40 milliseconds, the waiter sees the item appear on their tablet, and the kitchen sees the ticket light up on their screen. No page refreshes. No manual syncing. It just works.

Handling Intermittent Internet Connections

In India, internet reliability is the elephant in the room for cloud-based POS systems. A cafe in a basement might lose connection for 30 seconds. If a cloud POS stops working during a connection drop, the restaurant halts.

To solve this, Velo Dine's Windows app and Captain's App are built with an offline-first architecture using local SQLite databases synced via RxDB. When the internet drops, the local devices form a peer-to-peer mesh network over the local Wi-Fi router. The captain can still punch orders, the kitchen still gets the tickets, and the local Windows machine generates the bill.

The moment the internet connection returns, the background sync engine seamlessly uploads the queued transaction logs to the central PostgreSQL database in the cloud. The restaurant owner checking the dashboard from their home doesn't even notice the blip.

The Result: A 40% Increase in Efficiency

By eliminating manual order syncing and dropped tickets, cafes using Velo Dine have reported a 40% increase in table turnover speed during peak hours. Waitstaff no longer walk back and forth to the kitchen — they stay on the floor, serving guests.

This is what happens when you stop building "websites" and start building distributed software ecosystems.