Aegon — Distributed One-to-One Chat System

How do you guarantee a message was truly delivered — not just sent — in a distributed system where both servers and clients can crash at any moment?

What I Built

A WhatsApp-inspired distributed chat backend with correctness at its core. The system uses a strict 4-state message lifecycle: CREATED → SENT → DELIVERED → READ. The key design choice: only the client can assert DELIVERED and READ states — the server never auto-acknowledges.

This guarantees that server crashes, network drops, or silent client disconnects can never falsely mark a message as delivered.

Key Engineering Decisions

• MySQL as source of truth: Messages persist before delivery, so server crashes lose nothing.
• Redis TTL-based presence: Online state is soft state, renewed continuously and naturally expires on disconnect.
• Redis Pub/Sub per-server channels: Enables stateless horizontal scaling where servers don't need explicit awareness of each other.
• Nested ConcurrentHashMap<userId, Map<deviceId, session>>: Multi-device fan-out with near zero lock contention on reads.
• Offline replay on reconnect: findByReceiverIdAndDeliveredAtIsNullOrderByCreatedAt replays undelivered messages in order during registration.

Architecture

Client A → Server 1 → MySQL (persist) → Redis Pub/Sub → Server 2 → Client B
                    ↓
              Redis Presence (TTL per device per server)
            

What This Demonstrates

Correctness-first distributed systems thinking: not just building chat, but defining who has the authority to assert truth in a fault-prone distributed environment.