Trexind

Problem — One dashboard has to serve three verticals — clinics, restaurants, and salons — each built around a different core object (appointment vs. table order vs. service slot) — without forking the codebase per vertical.

Approach — Modeled a generic booking entity that every vertical extends with its own typed payload (patient record, table/menu order, service selection), so the booking, WhatsApp, and billing engines stay vertical-agnostic and only the extension schema changes.

Problem — Two customers can hit "book" on the same appointment slot or table within milliseconds of each other, especially right after a weekly promo goes out.

Approach — Booking slots carry a version field — the write that loses the race gets a conflict, not a silent overwrite, and retries against the now-current slot state. Went with optimistic locking over a pessimistic row lock because slot writes are short and contested rarely enough that a lock held across the request isn't worth the latency.

Problem — Weekly AI summaries and review-reply drafts run against Google Business Profile's rate-limited API for every connected business — one slow or throttled account shouldn't stall the batch for everyone else.

Approach — GBP sync and summary generation are jobs on a RabbitMQ queue, one consumer per business with its own backoff, so a rate limit on one account delays only that account's job, not the run. The last-synced profile snapshot and per-business rate-limit counters live in Redis, so a retry reads current state without hitting GBP again.

Problem — WhatsApp delivery retries and duplicate webhook events can double-fire a booking confirmation or a billing charge if handled naively.

Approach — Made every WhatsApp webhook handler idempotent, keyed on message ID, so a retried delivery updates state once instead of re-triggering booking or billing side effects. The booking engine holds up under 100+ concurrent bookings across verticals in load testing without a double-booked slot.