Made to Order (MTO) — Vinjo

Engineering Case Study on Vinjo by Vinay • An enterprise food ordering ecosystem featuring a React admin portal, Android self-service Kiosks, Kitchen Display System (KDS), and Azure .NET Core microservices backend.

{: .note }

Designed & architected for high-throughput restaurant peak hours, processing over 50,000 daily orders across 120+ retail locations with 99.99% uptime.

Executive Overview

Made to Order (MTO) is an enterprise-grade restaurant automation and ordering platform built to handle sub-second transaction routing between customer-facing Android Kiosks, Kitchen Display Systems (KDS), and Cloud inventory engines.

Before MTO, kitchen operations experienced high order latency during peak lunch hours due to monolithic database locks. We re-engineered the platform around event-driven microservices, achieving a 40% reduction in order processing latency and real-time sub-100ms kitchen ticket synchronization.

Architectural Breakdown

The architecture follows CQRS (Command Query Responsibility Segregation) and Event-Driven Pub/Sub patterns:

  1. Self-Service Kiosk Application: Android/Kotlin native app locked in kiosk mode using ESPER MDM for automated fleet management, OTA updates, and offline ordering fallback.
  2. Management & Admin Portal: React 18 SPA with TailwindCSS and Radix UI components for menu catalog configuration, dynamic pricing rules, and location-based store hours.
  3. Kitchen Display System (KDS): React web app utilizing ** WebSockets** for real-time order state updates, bump-bar integration, and preparation timers.
  4. Cloud Infrastructure: Built on Azure Kubernetes Service (AKS) and Azure App Services, utilizing Azure Service Bus topics for asynchronous message distribution and Redis Distributed Cache for fast menu lookups.

Technical Highlights & Engineering Challenges

Challenge 1: Peak Concurrency & Database Lock Contention

  • Problem: Under heavy load (200+ orders/minute across locations), direct database writes caused SQL Server lock contention, delaying kitchen ticket generation.
  • Solution: Transitioned from synchronous HTTP calls to asynchronous message queuing via Azure Service Bus. Orders are validated at the gateway, pushed to the Service Bus topic order-events-v1, and processed by background worker nodes.
  • Impact: Order placement response time reduced from 850ms to <120ms.

Challenge 2: Real-time Kitchen Order Synchronization

  • Problem: HTTP polling from KDS screens caused high CPU usage and delayed ticket display by 3–5 seconds.
  • Solution: Implemented a ** WebSocket hub** backed by a Redis backplane. When an order is paid at the Kiosk, a message triggers a broadcast to the location's specific KDS websocket group in real time.
  • Impact: Sub-100ms order delivery to kitchen screens upon payment authorization.

Performance & Operational Metrics

  • Order Processing Throughput: 50,000+ orders/day
  • Average KDS Sync Latency: < 95ms
  • System Uptime: 99.99% across all cloud services
  • Offline Resilience: Up to 4 hours of offline queue buffering on Android Kiosk local SQLite storage during network outages.