Design a Booking Notification System

Problem Design a system that notifies vendors when a booking happens on a travel site (flight, hotel, car). Each vendor chooses its channel: SMS, email, or a REST callback (webhook) that receives booking details.

Functional requirements

• Vendor onboarding with per-vendor channel config (and endpoint/credentials for webhooks).
• On every booking, deliver a notification to the right vendor over its chosen channel; support retries and delivery status visibility.

Non-functional requirements

• No lost notifications (at-least-once delivery); vendor endpoints are slow/flaky and must not back-pressure the booking flow.
• Scale to discuss: ~1K bookings/sec peak, thousands of vendors, webhook latencies up to seconds.

Key components

• Booking service emits a BookingCreated event (outbox pattern → queue, so the DB commit and event publish can't diverge).
• Notification service consumes events, resolves vendor config, and dispatches via channel adapters (SmsSender, EmailSender, WebhookSender behind one interface — strategy pattern makes channels pluggable).
• Retry infrastructure: per-channel retry queues with exponential backoff + DLQ; delivery-attempt log for status/auditing.

Deep dives / trade-offs

• Idempotency: at-least-once delivery means vendors may see duplicates — include a notification/booking id so receivers can dedupe.
• Webhook hardening: timeouts, circuit breaker per endpoint, HMAC signature so vendors can verify authenticity.
• Ordering guarantees (per-vendor partitioning) and what happens when a vendor is down for hours (DLQ + replay).