Booking Lifecycle Events

CRS publishes an event to an SNS topic every time a crs/website booking is created, updated, or cancelled. Internal services consume these by subscribing their own SQS queue to the topic — SNS owns the fan-out and retries; each consumer drains its queue at its own pace.

This stream is separate from the legacy booking-created SNS topic (which carries a thin event for the physical-unit assignment service). The lifecycle stream carries the full booking snapshot on every event.

At a glance

Transport	AWS SNS → SQS (per-subscriber fan-out)
Topic (dev)	arn:aws:sns:ap-south-1:910460496168:bard-booking-lifecycle-sandbox
Topic (prod)	arn:aws:sns:ap-south-1:910460496168:bard-booking-lifecycle-prod
Region	ap-south-1
Event types	booking.created, booking.updated, booking.cancelled
Message attribute	eventType (for SNS filter policies)
Payload	Full booking snapshot — see Payloads
Subscribe	Programmatic API — see Subscriptions

Architecture

┌────────────┐  booking created / updated / cancelled
│    CRS     │  (after the DB transaction commits)
│ publisher  │
└─────┬──────┘
      │ SNS Publish  (message = full snapshot, attribute eventType=booking.*)
      ▼
┌──────────────────────────────┐
│ SNS: bard-booking-lifecycle  │
└───┬───────────┬───────────┬──┘
    │ fan-out (optional filter policy on eventType)
    ▼           ▼           ▼
 SQS queue   SQS queue   SQS queue
 (consumer)  (consumer)  (consumer)

Delivery semantics

• After-commit. The event is built and published only after the booking's database transaction commits, so the snapshot always reflects the change that triggered it — never a partially-written row.
• Best-effort publish. A publish failure (or an unconfigured topic) is logged and swallowed; it never blocks or rolls back the booking write. If SNS is unreachable at that instant the event is not retried by CRS — treat the stream as at-least-once for the happy path, and reconcile critical state from the booking APIs if you need a hard guarantee.
• At-least-once from SNS→SQS. Once published, SNS retries delivery to each SQS subscription. A consumer can receive the same event more than once (and, across a retry, out of order). Make your handler idempotent — the envelope id is a stable dedup key, and every payload carries the booking's current state, so re-applying the latest snapshot is safe.
• No ordering guarantee. Two updates to the same booking may arrive in any order. Use the booking's own fields (updatedAt-style amounts/status in the snapshot) rather than arrival order when it matters.

When each event fires

Event	Reason	Fires when
booking.created	—	A booking is persisted (cart→booking, both online/Staah and Livbnb paths)
booking.updated	payment_collected	An online balance collection is applied to the booking
booking.updated	settled	A finance-approved offline payment settles the booking
booking.cancelled	—	A booking is cancelled (status → CANCELLED)

reason is only present on booking.updated. A future reason = modified is reserved for booking edits (VAS/meal changes). See Events for the full reference.