Developer Resources
Architecture
How Kaiten is put together — the gateway, the API and its Platform listener, PostgreSQL, and the event pipeline.
Kaiten follows a modular monolith architecture with vertical feature slices, event-driven integration, and infrastructure-as-code deployment.
System overview
Every request from your product, your team or the console passes through Envoy, which authenticates it before the API sees it. The Platform listener is the exception: it runs on its own port, outside Envoy and never on Kaiten Cloud, and authenticates its ksm_ credentials itself. A domain write and its event are committed in one transaction; the event pipeline carries the event from there to the audit trail, the activated connectors and your own consumers. Kaiten Cloud adds webhook delivery through Svix on top of the same pipeline.
Key design decisions
| Decision | Choice | Rationale |
|---|---|---|
| Architecture | Modular monolith | Simplicity + module isolation without microservice overhead |
| API Framework | Fiber + Huma v2 | OpenAPI generation, validation, structured operations |
| Database | PostgreSQL 17 | WAL logical replication for CDC, JSONB for flexible schemas |
| Event Delivery | Transactional outbox + CDC | Guarantees at-least-once without dual writes |
| Auth Gateway | Envoy | Single trust boundary: jwt_authn for provider JWTs, ext_authz for ksh_ tokens; the Platform listener authenticates ksm_ itself |
| Feature Flags | CEL + OFREP | Standard evaluation language + OpenFeature compatibility |
Where to go next
- API conventions — Request and response shapes, pagination, errors
- Event pipeline — Detailed CDC flow
- Data model — Tables, enums, constraints, and the ERD