Design decisions behind KitchenAsty — an open-source restaurant management system

In my previous post , I introduced KitchenAsty — an open-source, self-hosted restaurant ordering and management platform. People asked about the architecture, so this post dives into the core design decisions: how the real-time system works, how the database handles guest orders and price changes, how settings resolve from multiple sources, and how a data-driven automation pipeline lets restaurant owners set up custom workflows without writing code. 1. Real-Time Architecture: Rooms, Not Broadcasts A restaurant system has two audiences that need live updates simultaneously: kitchen staff watching for incoming orders, and customers tracking their delivery. Broadcasting everything to everyone would be wasteful and insecure. Socket.IO's room abstraction solves this cleanly. There are two room types: kitchen — a single shared room. Every kitchen display client joins it. When a new order arrives or any order changes status, the event goes here. order:{orderId} — one room per active order. Th