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.

Component	What it is	Notes
dwara	The gateway binary	Listeners, dataplane, snapshot, admin listener in one process
Listeners	Connection acceptors	TLS terminate (per-SNI certificates), SNI passthrough splice, or L4 TCP/UDP splice; PROXY protocol v1/v2 optional
Dataplane	The proxy engine	Route resolution, policy chain, plugin phases, streaming proxy — buffers nothing by default
Snapshot	Immutable config state	Routes, upstream pools, TLS material, and auth state swap atomically behind an ArcSwap
Admin listener	mTLS-only management surface	Optional; GET/PATCH /config, /health, /stats
SQLite state store	Durable identity state	Optional; stored consumers, credentials, quota counters
Embedded analytics	Request records + rollups	Optional; its own SQLite file, bounded disk
dwara CLI	Operator tooling	validate, 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:

Component	Edition	Role
dwara-controller	Enterprise	The 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-edge	Enterprise	A 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 gate	Enterprise	Verifies the signed license at startup and activates enterprise features per claim; a degraded license falls back to OSS behavior
Redis backend	Enterprise	Shared GCRA rate-limit buckets, the two-tier distributed cache, and config-convergence generation state
dwara (embedded)	Both	The 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

Every dataplane capability — the proxy-wasm plugin host, the native filter chain, nano-services, CEL expressions, protocol translation, the AI gateway — compiles into the default OSS build; there are no optional capabilities to enable. The only compile-time switch beyond that is the ent cargo feature, which adds the enterprise modules (and requires a license to activate them). See the feature reference for the complete edition-by-edition list with build commands 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 two live plugin paths (Proxy-Wasm modules and native filters) on one dispatch chain, the plugin lifecycle and health states, nano-services, the five extension traits, and what is still scaffolded.
• Observability — the request ID, access log, metric families, trace spans, and how they correlate across the request path.

Where to go next

• Concepts and taxonomy — the vocabulary of Dwara: listeners, routes, services, upstreams, consumers, policies, and how they relate.
• Editions: OSS vs Enterprise — which features ship in which edition and how the license gate works.
• Getting started — run a gateway locally.
• Configuration — the YAML shape and the config pipeline.
• Operations — reload, shutdown, health, hardening.
• Observability — logs, metrics, tracing.
• Feature reference — what each edition includes, with build commands and maturity status.