# ADR 0001: Synchronous External Calls For MVP

## Status

Accepted

## Context

The MVP relies on OTP delivery, booking notifications, and payment gateway calls. Introducing a task queue (Celery/RQ) would add infrastructure (Redis, workers, retries) and operational complexity that is not required for the early launch.

## Decision

For the MVP, OTP sends, booking notifications, and payment gateway calls run synchronously in the request/response path with strict timeouts. A task queue will be revisited when traffic grows or operational needs change.

## Consequences

- Faster initial delivery with fewer moving parts.
- Increased latency risk on endpoints that call external providers.
- Payment and OTP failures are surfaced to clients immediately (correct behaviour — clients need to know).
- Notification failures are absorbed: `notifications/services.py` catches provider errors, stores them as `FAILED` status, and never surfaces them to the client. A failed booking SMS does not cause the booking request to fail. This means notification failures require active monitoring rather than appearing in client-facing error rates.

## Alternatives Considered

- Celery + Redis for all external calls: rejected for MVP due to infra overhead.
- Hybrid async for notifications only: not wrong in principle, deferred for operational simplicity. The three call types have genuinely different semantics:
  - **Payment creation**: synchronous by design — the client needs the Moyasar redirect URL before the response returns.
  - **OTP sends**: synchronous by design — users expect immediate confirmation that the code was sent.
  - **Booking notifications**: fire-and-forget by nature — the booking is already committed and the client does not wait for delivery confirmation.
  When notification latency becomes a problem (e.g. under load or with slow SMS providers), only notifications need to move off the request path. Payments and OTP sends should remain synchronous regardless.

## Related

- `docs/architecture.md`