Connection Lifecycle Abstractions for Distributed Workers

[wibed]

Clients using traditional network transports (HTTP, SMTP, WebSocket, TCP, etc.) require a mechanism to discover and communicate with workers within a cluster.

Today, each transport tends to expose its own connection semantics, resulting in duplicated implementations for connection pooling, cleanup, lifecycle management, multiplexing, health monitoring, and resource ownership.

It would be beneficial to introduce a transport-agnostic connection management abstraction that can be specialized by individual protocols while sharing common lifecycle behavior.

[wibed]

for example a session pool or psql's transaction multiplexer as as transaction pool.
these would not be able to be nested onto each other and therefor live side by side, within the cluster.

[wibed]

If such a structure — a session registry and a transaction multiplexer, together forming the connection management surface — could live side by side on the routing edge of the cluster:

The major pitfall is reintroducing session affinity under the guise of transaction pooling, by pinning a connection to a specific backend. Even so, some information has to cross the boundary:

• node/shard identifier :: the resolved output of the registry lookup, which becomes the pool key the multiplexer indexes on.
• class/affinity tag :: metadata that routes between the two logics — does this connection belong to session-mode or transaction-mode pooling.
• capacity backpressure :: a way to tell the routing layer when a node's pool is saturated or degraded.
• transaction boundary :: custom, protocol-aware behavior to determine the start/end of a transaction, preserving lifecycle correlation.

Is it even possible to implement this as a protocol? pgbouncer would be the exemplary case.

By nature, an edge at the head begets an edge at the tail — distributed, causally ordered logs across the cluster would be a requirement for debugging.