Skip to content

Architecture overview

This page is a high-level map of how Dwara handles a request and how it manages its own state, for anyone deploying or operating the gateway.

Editions at a glance

Dwara ships in two editions from one codebase:

  • The OSS edition (the default build, Apache-2.0) is a single, self-contained gateway binary. One process owns routing, policy, TLS, and its own config file — everything needed to run a gateway, including a fleet of independent instances behind one load balancer.
  • The Enterprise edition (built with the ent cargo feature and activated by a license) adds the features that span multiple instances or need external infrastructure: a control plane / data plane split, shared Redis-backed rate limiting and caching, config convergence across a fleet, Vault/KMS secrets, multi-tenant workspaces with RBAC and audit, and external policy engines.

The request path is identical in both editions — enterprise features extend how instances are managed and coordinated, never how a request is proxied. See Editions: OSS vs Enterprise for the complete feature-by-feature comparison and how the license gate works.

Software components

The OSS gateway: one process

The default deployment is a single dwara process in embedded mode: data plane, admin surface, and state all live in one binary.

ComponentWhat it isNotes
dwaraThe gateway binaryListeners, dataplane, snapshot, admin listener in one process
ListenersConnection acceptorsTLS terminate (per-SNI certificates), SNI passthrough splice, or L4 TCP/UDP splice; PROXY protocol v1/v2 optional
DataplaneThe proxy engineRoute resolution, policy chain, streaming proxy — buffers nothing by default
SnapshotImmutable config stateRoutes, upstream pools, TLS material, and auth state swap atomically behind an ArcSwap
Admin listenermTLS-only management surfaceOptional; GET/PATCH /config, /health, /stats
SQLite state storeDurable identity stateOptional; stored consumers, credentials, quota counters
Embedded analyticsRequest records + rollupsOptional; its own SQLite file, bounded disk
dwara CLIOperator toolingvalidate, fmt, diff, lint, schema, import, upgrade — plus the dwara-loadgen load-generator rig

An OSS fleet is simply N independent dwara processes with the same config file (or one per team/service). Nothing coordinates them — that is what the enterprise edition adds.

The Enterprise topology: control plane + data planes

With the ent feature, two more binaries are compiled and the topology gains a management layer:

ComponentEditionRole
dwara-controllerEnterpriseThe control plane: watches config sources, compiles generations, pushes them to edges over a gRPC stream (xDS-inspired). Multiple controllers run HA with leader election
dwara-edgeEnterpriseA data-plane instance that subscribes to the controller's stream and applies config updates without restart. Caches the last received generation, so the fleet keeps serving through a controller outage
License gateEnterpriseVerifies the signed license at startup and activates enterprise features per claim; a degraded license falls back to OSS behavior
Redis backendEnterpriseShared GCRA rate-limit buckets, the two-tier distributed cache, and config-convergence generation state
dwara (embedded)BothThe embedded mode remains first-class in enterprise builds — the controller and an embedded gateway run the same compile-and-publish pipeline, just without the gRPC transport

The key property: an edge applies a config generation through the same validate -> compile -> atomic publish pipeline as an embedded gateway, so behavior is identical whether config arrives from a file, the admin API, or the controller's stream.

Compile-time capabilities

Both editions compile every dataplane capability into the default build (default OFF) so the base binary stays small. These are OSS — no license involved. See the feature reference for the complete list of all 29 flags with build commands, dependency chains, and maturity status.

Architecture in detail

The overview above is the 30-second map. The following pages go into each area in depth:

  • Request pipeline — the fixed order of stages every request passes through, split into routing/policy and proxy/response phases, with two detailed flow diagrams and the operator-facing consequences of the ordering.
  • Connection and TLS — how listeners accept connections, the six listener modes (terminate, passthrough, cleartext, H3/QUIC, L4 TCP, L4 UDP), PROXY protocol, and upstream TLS options.
  • Config, state, and extensions — the four-stage config pipeline (parse -> validate -> compile -> publish), hot reload, the three kinds of durable state, and the five swappable extension-point traits.
  • Error handling — the unified JSON error envelope, the complete status-to-code mapping, and upstream error classification.
  • Resilience — the layered state machines (endpoint health, circuit breaker, retry budget, adaptive rate limiting) and how they compose to keep traffic flowing when upstreams degrade.
  • Security — the authentication dispatch order, the authorization evaluation model, secret resolution, and how they fit into the request pipeline.
  • AI gateway — the AI request flow, the adapter translation model, alias resolution, and the policy-scoped governance, guardrails, and budgets.
  • Plugins and extensibility — the shared phase model, the dispatch chain, and the lifecycle of a plugin instance across the three runtimes (native, Proxy-Wasm, Extism).
  • Observability — the request ID, access log, metric families, trace spans, and how they correlate across the request path.

Where to go next