Overview
Rebuilding a messaging client is the quickest way to find out what makes real-time systems difficult. Message ordering, delivery status, presence, reconnection.
Typing indicators and read receipts look trivial from the outside. Both are distributed state problems wearing a very small piece of UI.
- Role
- Sole engineer.
- Year
- 2025
- Stack
- ReactNode.jsExpressMongoDBSocket.IOJWT
Engineering
The decisions that mattered.
- 01
Message status as a state machine
Sent, delivered and read are explicit transitions with server acknowledgement behind each one, so the ticks cannot drift away from what the server believes.
- 02
Reconnection without gaps
On reconnect the client asks for messages since its last known id instead of trusting the socket to have caught everything.
Design decisions
Why it looks and behaves the way it does.
I designed this as well as built it. These are the interface calls I made and the reasoning behind each one.
Status glyphs stay nearly invisible
Delivery ticks are information you glance at occasionally, so they are small, low-contrast and always in the same place. They should never compete with the message.
The typing indicator holds its space
The indicator occupies reserved height, so the thread does not jump every time somebody starts and stops typing.
Outcomes
What shipped.
- Delivery status consistent with server state
- No message loss across reconnection