Where should the database routing and pooling layer live — inside the application's driver, as a sidecar next to each application instance, or as a centralized proxy tier — and how do you keep it from becoming the system's single point of failure?

## The real question Routing has to happen somewhere. The design choice is *where the decision lives*, and each answer trades blast radius against control. ## Driver-side routing The connection string lists every node plus a role requirement; the driver probes until it finds one that matches. - **For**: zero extra infrastructure, lowest latency, no additional failure domain. Failure of any database node is handled locally and instantly. - **Against**: the routing behaviour is whatever each language's driver implements, and the fleet is only as consistent as its least-updated service. Changing routing policy means redeploying every application. There is no place to drain connections, no queue to absorb a promotion gap, and no global view of how many connections the database is receiving. Discovery is only as fresh as the next connection attempt. - **Fits**: small, homogeneous stacks; internal services in one language; teams that value having nothing between app and database. ## Sidecar pooler A pooler process per host or per pod, reached over loopback or a local socket. - **For**: language-agnostic, sub-millisecond hop, and a failure takes down exactly one application instance — the same blast radius the instance already had. It can also absorb the local pool's churn so the database sees stable long-lived connections. - **Against**: configuration and version now exist in N places, so a routing change is a fleet-wide rollout. Crucially, **there is no global connection budget**: with 300 pods each holding 20 connections you are asking the database for 6,000, and the engine's per-connection cost (a process or thread, plus memory) makes that the classic way to fall over. Some multiplexing helps, but the arithmetic must be done explicitly. - **Fits**: containerised fleets with many small instances, polyglot services, environments where a shared component is politically or operationally hard. ## Central proxy tier A handful of proxies that every client connects to. - **For**: one place to change and observe routing; genuine fan-in, so thousands of client connections become a bounded number of backend connections; the ability to pause and queue during a switchover so clients see latency, not errors; read/write splitting, throttling and per-tenant limits in one component. - **Against**: an extra network hop on every query — usually a fraction of a millisecond, but it is now in every latency budget; a component with its own capacity, upgrades and failure modes; and if it is a single instance, the availability of the whole system is the availability of that process. Pooling modes also matter here: transaction-level multiplexing is what delivers the fan-in, but it breaks session-scoped features (session variables, temporary tables, advisory locks, some server-side prepared statements), so it constrains what applications may rely on. - **Fits**: large or polyglot fleets, many services sharing one database, environments needing central policy. ## Removing the single point of failure A proxy tier is only a SPOF if you build one instance of it. The standard treatment: - **Multiple stateless instances.** Nothing routing-critical is stored in the proxy, so an instance can be killed and replaced; the cost of losing one is a reconnect. - **A cheap front-end**: a floating IP shared by a proxy pair, a network load balancer with health checks, or anycast. The state that must move is now a routing entry, not a database. - **Client-side redundancy**: list several proxy endpoints in the connection string, so clients survive one being unreachable without waiting for the front-end to react. - **Independence from the database's control plane**: the proxy should keep serving its last known good routing if the cluster manager is unavailable, and fail closed for writes rather than guessing. - **Capacity headroom**: size the tier so that losing one instance does not saturate the rest, and cap per-client connections so one misbehaving service cannot exhaust it. ## The common hybrid Many mature systems use two layers: a sidecar or in-process pool that absorbs local connection churn, and a central routing tier that decides which node is primary and enforces the global connection budget. It costs one more hop than either alone but keeps blast radius small while retaining a single control point. ## How to decide Ask: how many client languages, and do you control them? How many application instances multiplied by pool size, against the database's connection ceiling? How fast must a routing change reach every client? What latency budget does an extra hop consume? And what does an outage of the routing layer cost relative to an outage of the database itself — if the answer is "the same", the layer must be engineered to the same standard as the database it fronts.