Mezani
Multi-tenant restaurant operating system
Independent restaurant groups needed a single platform to run QR ordering, kitchen display, and analytics across multiple branches — without each tenant's data, staff, or traffic interfering with another's.
- →Isolating tenant data without the operational cost of separate databases per customer
- →Delivering kitchen order updates to screens in under 200ms during peak service
- →Scoping staff permissions across branches, roles, and trial accounts from a single token
- →Keeping the system close to feature-complete while shipping weekly without destabilizing production
Schema-per-tenant isolation with scoped claims
Each tenant gets its own PostgreSQL schema, while a single Go/Gin API resolves the active schema from JWT claims on every request — so tenant boundaries are enforced before a query is ever built.
Redis Pub/Sub-backed kitchen display
Order events are published to per-branch Redis channels and fanned out over WebSockets to kitchen displays, keeping delivery consistently under 200ms even with multiple concurrent branches.
Claims-driven RBAC across branches and trials
A single permissions map, encoded in JWT claims with refresh-token rotation, governs branch selection, manager-level access, and time-boxed trial accounts — no per-request database lookups for authorization.
AI operations assistant
An assistant (powered via the Claude API) answers natural-language questions about sales and ordering patterns by querying aggregated tenant data — surfacing insights owners would otherwise need a report for.
- Sub-200ms order-to-kitchen-display latency under concurrent multi-branch load
- Single shared deployment serving isolated tenant data via schema-level boundaries
- Refresh-token rotation and RBAC bugs resolved across manager, branch, and trial flows
- System brought to near feature-complete status while remaining deployable weekly