> ## Documentation Index
> Fetch the complete documentation index at: https://docs.praeto.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> How Praeto Dispatcher moves events from publishers to customer webhook endpoints.

# Architecture

Praeto Dispatcher is currently designed around a Cloudflare-first backend:

* **Cloudflare Workers** handle HTTP APIs, authentication, validation, event ingestion, replay requests, admin operations, and queue consumers.
* **Cloudflare Queues** decouple event acceptance from outbound webhook delivery.
* **Neon Postgres** stores tenants, API keys, endpoints, events, deliveries, attempts, usage data, and rate limit counters.
* **Cron triggers** run retention cleanup.

```mermaid theme={null}
flowchart TD
  A[Publisher app] -->|POST /v1/events| B[Cloudflare Worker API]
  B --> C[(Neon Postgres)]
  B --> D[Cloudflare Queue]
  D --> E[Worker queue consumer]
  E --> F[Customer endpoint]
  E --> G[(Delivery attempts)]
  G --> H[Metrics / health / usage APIs]
```

## Design principles

### Accept quickly, deliver asynchronously

`POST /v1/events` returns after the event and matching delivery records are accepted and queued. Actual endpoint delivery happens asynchronously.

### Store enough to debug

Praeto records events, deliveries, attempts, status codes, response bodies, retry state, endpoint health, and usage counters so customers and operators can answer what happened.

### Protect the platform

Praeto includes SSRF blocking, payload limits, endpoint quotas, fan-out limits, monthly usage limits, and rate limiting so one bad tenant or endpoint cannot burn infrastructure or queue capacity.