We run an in-app support chat for a marketplace: buyers, sellers and support agents talk in one-to-one and small group conversations, on web and mobile, often on flaky mobile networks. The first version stored messages in PostgreSQL, pushed them over WebSocket, and set a read boolean when the recipient opened the thread. It worked in the demo. In production we collected three kinds of bug reports: messages appearing in the wrong order, the same message showing twice after a reconnect, and "...
Designing chat delivery and read receipts over WebSocket: ordering, ACKs, offline sync
Our support chat showed messages out of order, double ticks that never turned blue, and duplicates after reconnects. We rebuilt delivery around per-conversation sequence numbers, client message ids, device cursors and read watermarks. This is the protocol, schema and code.
This is a paid story
Subscribe to read the full content, access all paid stories, and support the authors.
Add a label
Embed this post
<iframe src="https://www.hibug.me/chat-system-delivery-read-receipts-design" width="700" height="420" frameborder="0" loading="lazy"></iframe>
I am a Senior Software Engineer with over a decade of hands-on experience building, scaling, and maintaining complex systems across the full stack—spanning frontend, backend, and DevOps. Over the last 10 years, I have navigated diverse architectures and untangled some of the most frustrating, elusive bugs in production. I believe that every production incident is a massive learning opportunity. Having discovered hibug.me, I am excited to contribute to this knowledge base, breaking down root causes, and sharing verified fixes to help fellow developers debug faster and build more resilient systems.
Comments
0No comments yet. Be the first to comment!
Sign In to post a comment.