The engineering bottleneck with assembled stacks
Product squads rent a socket vendor because the alternative looks like operating socket servers: sticky processes, a pub/sub backbone, presence bookkeeping. The vendor is fine until its data model or pricing shapes the feature, and the live layer becomes the one part of the system nobody can draw on the architecture whiteboard.
Architecture on the Software Lifecycle Cloud
Connect, message, and disconnect are function invocations over the socket route. Presence is a table row per connection with a heartbeat timestamp; fanout targets are read from subscription rows rather than held in process memory, so any function instance can serve any socket. Streams of notifications are written as rows first and pushed second — a reconnecting client catches up from the table, which is the difference between live and eventually-informed.
State in tables beats state in processes
Holding presence in a table makes the failure modes boring: an instance dying loses no truth, a deploy does not empty the room, and “who is online” is a query the product can also use. Heartbeat expiry marks the abandoned rows a sweep clears. This is deliberately less exotic than a socket cluster — and for presence-and-notifications scale, boring is the feature.
- Websocket routes target Go functions; the handler owns connect, message, and fanout logic
- Reconnect catch-up reads missed rows from the notifications table — live and history agree
- Presence leaks are a heartbeat sweep, not a memory leak with a pager attached
Scale, said plainly
Thousands of concurrent rooms with modest message rates fit comfortably; a global consumer chat with millions of simultaneous sockets is a specialised system’s job. Choosing this stack means valuing one declared project over a separate realtime vendor — a good trade at product scale, a wrong one at broadcast scale, and this page would rather say so.
Frequently asked questions
It is a platform constraint: websocket routes target Go functions. Long-lived non-socket work belongs in workers; the socket handler itself stays a function, which keeps the realtime surface small and declared.
Notifications persist as rows before fanout. On reconnect the function reads what the client missed and then resumes live delivery, so the stream and the history are the same data — no separate “load earlier messages” subsystem.
Connections write heartbeat timestamps on their rows; staleness is computed at read time and a sweep clears the dead. Presence across instances stays consistent because the table, not any process, holds it.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.