mohd/Salon

Files

T

mohd 229975c612 docs: revise ADR 0001, risks, and architecture for accuracy

- 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>

2026-03-01 23:30:04 +03:00

2.0 KiB

Raw Permalink Blame History

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.

docs/architecture.md

2.0 KiB Raw Permalink Blame History