The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
What happens after you click “Place Order”? 🍔
Behind that simple action, multiple systems can start working together — payment, inventory, kitchen, delivery, and notifications.
But how do they know that an order has been placed?
That’s where Event-Driven Architecture comes in.
Instead of one system controlling every step, an event is published and the services that need it respond independently.
One Event → Multiple Services
In this MALtech Weekly Series, we break down Event-Driven Architecture through a simple food-delivery story and show what happens behind the scenes.
MALtech — Technology beyond EDGE
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
A self-initiated product: a booking and ordering system for a billiard club in Tbilisi. I designed it in Figma from scratch and built all of it, from the interface to the database.
Guests call the club and nobody answers. They arrive and every table is taken. They want food and wait at the bar. Side Pocket moves all of that to the website.
Key decisions
No guest accounts. A booking needs a name and a phone number. The guest gets a private link to move, extend or cancel. The link is the account.
A 15-minute hold. Guests check in with "I'm at the table." A table nobody claims goes to the waitlist, and the next person gets the same 15 minutes.
Ordering tied to the table. Guests order from their phone during the game, add time themselves and see the bill as it grows.
One screen for staff. Every table's state for the night, late arrivals and orders to serve pinned to the top, bookings and orders boards, alerts in Telegram.
A Telegram bot. It understands "table for 4 tonight at 8" in English or Russian and finishes the booking with buttons.
Scope
Guest site with live availability, single and group booking, waitlist, private booking page, table page with menu, cart and bill, email confirmations and reminders, staff dashboard, Telegram bot.
Stack
React 19, TanStack Start, TanStack Router and Query, Tailwind 4, Radix UI, Supabase Postgres with row-level security, pg_cron, Brevo and Resend, Telegram Bot API, Vitest.
Business rules sit in plain functions, separate from the UI and the database, with 73 tests. Only server functions touch the database.
My role
Product design, UI design, front-end, back-end, database, integrations.
Live demo: side-pocket.lovable.app
Built for the #LovableChallenge by @Contra and @Lovable. #BuiltWithLovable😊
nicety accomplished.. great work
Creating immersive digital experiences with smooth website animations ✨
Designed & developed by Usman DevHub Tech & Creative Studio.
We create premium websites with modern UI, interactive animations, and unique visual experiences that help brands stand out. 🚀
Want a website like this for your brand?
DM us and let's discuss your project.
#WebDesign #WebDevelopment #WebsiteAnimation #UIDesign #CreativeStudio #DigitalAgency #UsmanDevHub
Building a 4-role real-time SaaS taught me one uncomfortable lesson: the hard part was never the code.
I've been building RestaurantOS — one platform connecting Owner, Kitchen, Waiter, and Cashier in a single live workflow (Table → Order → Kitchen → Serve → Billing → Reports).
The tech stack was the easy part. The real challenge: keeping 4 different roles in sync in real time without any of them stepping on each other's data — a waiter updating a table while the kitchen marks an item ready while the cashier is mid-billing.
That forced decisions most tutorials never cover:
⚡ How much state should live client-side vs. source-of-truth server-side
⚡ What "real-time" actually needs to mean per role (a kitchen screen needs sub-second updates, a report dashboard doesn't)
⚡ Designing failure states — what happens when the waiter's app loses connection mid-order
Currently redesigning the UI/UX layer too (motion, better visual hierarchy) while keeping this real-time core intact.
If you've built multi-role or real-time systems — curious what broke first for you. And if you're a founder who needs something like this built, my DMs are open.
the role based flow is easy to follow. what part was hardest to keep real time?