Systems

The "systems" lens covers the long-lived components that exist inside every Envoy process. These are the architectural blocks that run continuously, own their own state, and are connected together by the request pipeline. Most live under source/common/ or source/server/ — they are core Envoy, not extensions.

Pages in this section

Page	Subsystem
Threading model	The lock-free per-worker model that everything else is built on.
Server lifecycle	Server::InstanceImpl, init manager, drain manager, watchdog, overload manager.
Listener manager	Creates, reconfigures, and drains listeners. The thing that turns LDS into a bound socket.
HTTP connection manager	The L7 dispatcher: HTTP/1+2+3 codecs and the HTTP filter chain.
Filter manager	The L7 filter execution engine, used by HCM.
Router	The terminal HTTP filter that selects a cluster and forwards the request.
Cluster manager	The catalogue of upstream clusters; routes get hosts from here.
Connection pools	Per-host upstream connection multiplexing for HTTP/1, HTTP/2, HTTP/3, TCP.
Stats	The symbol-table-backed stats system and stat sinks.
Runtime	Feature-flag/key-value store consulted at request time.
Admin	The HTTP admin interface for operators.
Hot restart	Live binary upgrade via shared memory and Unix domain sockets.

How systems compose

graph TB
    Server[Server::InstanceImpl<br/>source/server/server.cc]
    Server --> ListenerMgr[ListenerManager<br/>source/common/listener_manager/]
    Server --> ClusterMgr[ClusterManager<br/>source/common/upstream/cluster_manager_impl.cc]
    Server --> Stats[Stats<br/>source/common/stats/]
    Server --> Runtime[Runtime<br/>source/common/runtime/]
    Server --> Admin[Admin<br/>source/server/admin/]
    Server --> Drain[DrainManager<br/>source/server/drain_manager_impl.cc]
    Server --> Overload[OverloadManager<br/>source/server/overload_manager_impl.cc]
    Server --> GuardDog[GuardDog<br/>source/server/guarddog_impl.cc]
    Server --> Workers[Workers<br/>source/server/worker_impl.cc]

    ListenerMgr -.assigns.-> Workers
    Workers --> HCM[HTTP connection manager<br/>per filter chain]
    HCM --> FilterMgr[FilterManager]
    FilterMgr --> Router
    Router --> ClusterMgr
    ClusterMgr --> ConnPool[ConnectionPool]

What's not in this section

• The wire-protocol filters themselves (HTTP filters, network filters, transport sockets, …) live in features because each is one instance of a broader extension family.
• The mobile binary is in apps.
• The xDS protocol that pushes config into these systems is in features/xDS configuration.

Reading order

If you have read overview/architecture and want a deeper understanding of the data plane, the recommended path through this section is:

1. Threading model — sets up the constraints everything else operates under.
2. Server lifecycle — what happens at startup.
3. Listener manager → HTTP connection manager → Filter manager → Router → Cluster manager → Connection pools — the hot path of an HTTP request.
4. Stats, Runtime, Admin, Hot restart — the cross-cutting infrastructure.