Chat Service

01What does this layer promise the product teams building on it?

Hold one long-lived socket per online device and deliver any message published to that user in under a second — receipts, inbox rules, and other product semantics build on top of this layer.

02One-to-one and group chat — same infrastructure?

Yes: a 1:1 chat is just a group of two — one routing layer serves both, and only the fan-out strategy changes with group size.

03Do we store history, or only relay live traffic?

Every message is persisted before delivery, and any client can range-scan a conversation’s history in time order.

04Is presence this layer’s job?

Yes, as derived state: connection servers already know which sockets are alive, so presence is aggregated from socket state — never a separate per-client broadcast firehose.

05Can we deploy new connection-server code without users noticing?

Yes: servers drain gracefully — announce, stop accepting, let clients reconnect elsewhere with jittered backoff — and no in-flight message is lost because persistence precedes delivery.

06What happens to a message when the recipient is offline?

It waits in the conversation partition: delivery on reconnect is a partition read, so the socket layer never buffers for absent users.

01How many users are connected at once, and what does that force?

300M concurrent connections — the socket IS state, so this is a stateful fleet with a registry, not a stateless pool behind a load balancer.

02What latency counts as real-time here?

Under 500 ms sender-to-recipient in-region — which rules out polling and anything that parks messages behind batch layers.

03Can a message be lost?

No message loss: persist before acknowledging the sender, deliver at-least-once, and let clients dedup by message id.

04What write volume must the storage tier absorb?

Billions of appends a day — storage is write-optimized and partitioned by conversation, so a history scan never crosses partitions.

05A server dies holding a million sockets — how bad is that allowed to be?

A dying server is a bounded event: clients reconnect with jittered backoff, the registry evicts its lease in seconds, and the reconnect storm must not cascade across the fleet.