🍔 Orchestrating the Cloud Kitchen

The physical operation of a Cloud Kitchen (a kitchen with no dining room, cooking exclusively for delivery) is a logistical marvel. However, the software running it is frequently pushed to breaking point.

Imagine a large Indian cloud kitchen operating 15 different 'virtual' brands simultaneously. On a busy Friday night, Swiggy and Zomato are bombarding their central Point of Sale (POS) system with hundreds of API webhooks per minute regarding new orders, rider allocations, and cancellation requests.

The Chaos of Polling

Many early kitchen POS systems relied on constant HTTP polling. They would query the Zomato API every 10 seconds: "Any new orders?"

During peak hours, these monolithic APIs would rate-limit the kitchen, creating catastrophic order delays. By the time the kitchen received the order, the delivery rider had already arrived to pick it up.

Event-Driven Asynchronous Queues

Modern Indian FoodTech platforms survive by strictly utilizing Event-Driven Architectures.

Instead of polling, the aggregator pushes webhooks directly to an AWS API Gateway endpoint. This endpoint does not process the order. If it tried to, a database lock would crash the system.

Instead, the Gateway instantly dumps the webhook JSON into an Amazon SQS Queue and returns a strict 200 OK.

A series of independent Node.js worker nodes then slowly consume the queue at a steady, manageable rate. Even if 1,000 orders arrive in 5 seconds, the system doesn't crash; the queue just gets slightly longer. The workers parse the JSON, standardize the chaotic schema differences between Zomato and Swiggy, and push a clean websocket event down to the specific kitchen iPad displaying the chef's ticket.