How do you serve clinics, restaurants and salons from one booking system?

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.

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.

Originally published at sakshamjain.codes/blog/one-booking-engine-for-clinics-restaurants-salons. Need this built? See my services on NexoRush or message me.