How do you serve clinics, restaurants and salons from one booking system?
By Saksham Jain ·
Model a generic booking entity and let each vertical extend it with a typed payload: a patient record, a table order or a service selection. The booking, notification and billing engines stay vertical-agnostic, so only the extension schema changes per vertical and the codebase never forks.
From the production case study Trexind.
Why not build a separate booking flow per vertical?
Clinics book appointments, restaurants take table orders and salons sell service slots, so each looks like a different product. Forking per vertical triples the booking, WhatsApp and billing code and makes every fix land three times. The shared parts are the same; only the core object differs.
What does a generic booking entity look like?
A base booking with the shared fields (business, customer, slot, status) plus a typed payload per vertical: a patient record for clinics, a table and menu order for restaurants, a service selection for salons. Engines operate on the base; vertical code only reads and writes its payload.
How do you avoid double-booking a slot?
Give each slot a version field. If two customers hit book within milliseconds, the write that loses gets a conflict instead of a silent overwrite and retries against the current slot state. Slot writes are short and rarely contested, so optimistic locking beats a lock held across the request.
How do you keep one throttled business from slowing everyone's weekly summary?
Run Google Business Profile sync and summary generation as jobs on a RabbitMQ queue with one consumer per business, each with its own backoff. A rate limit on one account then delays only that account's job. Last-synced snapshots and per-business rate-limit counters live in Redis.