mohd
229975c612
- ADR 0001: distinguish payment/OTP (sync by design) from notifications (fire-and-forget); correct misleading claim that notification failures surface to clients — they are silently absorbed as FAILED status - risks.md: upgrade USERNAME_FIELD entry with concrete breakage (admin, create_superuser, JWT lookup); add booking overlap race condition with root cause and fix (select_for_update) - architecture.md: document notification/OTP provider coupling as an MVP shortcut and note the Phase 2 fix (dedicated NotificationProvider) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
34 lines
2.0 KiB
Markdown
34 lines
2.0 KiB
Markdown
# 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`
|