Request and Data Flow

Public request flow

1. The browser requests a public page or API resource.
2. Web rendering or the client calls the versioned API.
3. The API applies DTO/schema validation and public visibility rules.
4. PostgreSQL supplies authoritative detail or the search service queries the derived index with a PostgreSQL fallback.
5. The API maps the result to a safe response contract.

Admin request flow

1. An authenticated Admin request reaches the API.
2. Session/JWT context identifies the user.
3. Role and fine-grained permission guards run.
4. The domain service applies resource ownership or dealer membership rules.
5. Sensitive mutations are audited and any enabled side effects are queued.
6. The API returns a redacted administrative contract.

API lifecycle representation

request → validate → authenticate (if protected) → authorize → domain service
        → PostgreSQL transaction → audit/event/queue side effect → response

The API remains the business boundary. A browser may display a state or retry a request, but it cannot promote a listing, approve a policy, or mark payment paid by changing client-side data.

Flow qualification

Search, media processing, notifications, and email may be asynchronous. The current source also contains rollout gates and disabled worker consumption for some registered queues, so documentation distinguishes a requested side effect from a confirmed processed side effect.