Real-Time Infrastructure — Socket Layer, Redis Queue, and Delivery Guarantee

To deliver a seamless, low-latency, and high-reliability messaging experience, Sudo employs a scalable real-time infrastructure built on persistent WebSocket connections, a Redis-based pub/sub message queue, and robust delivery confirmation mechanisms. This architecture ensures that messages are delivered in milliseconds, even under heavy network load.

1. WebSocket-Based Real-Time Messaging

Sudo maintains persistent WebSocket connections to enable bi-directional communication between clients and the messaging engine. These sockets power:

• Instant message transmission with minimal latency.

• Real-time group and channel synchronization within milliseconds.

• Immediate delivery acknowledgment from recipient clients.

• Event-driven updates for read receipts, typing indicators, and presence tracking.

Each WebSocket connection is authenticated via a Web3 wallet signature, ensuring only verified users can send and receive messages.

2. Redis Pub/Sub Queue System

Redis serves as the high-performance in-memory broker that connects the messaging engine to delivery endpoints.

The Redis-based pipeline includes:

• Publisher: Sends encrypted messages into Redis channels for routing.

• Subscriber: Listens for incoming messages and delivers them to connected user sessions.

• Retry Queue: Captures failed or delayed deliveries for reprocessing.

Key Benefits:

• Horizontal scalability to handle spikes in concurrent connections.

• Near-instant broadcasting to all subscribers in large groups and channels.

• Fault tolerance through retry buffers and delayed message re-queues.

3. Delivery Pipeline Architecture

The message flow operates as follows:

1. Client Connection: User connects with Web3-authenticated WebSocket session.

2. Message Publish: Encrypted message is sent to Redis publisher.

3. Queue Processing: Queue manager processes the message and sends it to relevant subscribers.

4. Delivery: Receiver’s WebSocket client receives the message in real time.

This architecture ensures minimal hops between sender and recipient, reducing delivery times to under 100ms for most messages.

4. Message Delivery Guarantee (MDG)

Sudo enforces delivery integrity with multiple confirmation and retry layers:

• Acknowledgment Tokens: Every sent message requires confirmation from the recipient client.

• Retry Buffers: Failed deliveries are retried up to three times with 5-second intervals.

• Status Sync: Sent, delivered, and read states are stored in PostgreSQL for reliability.

• Local Drift DB: Messages are cached on-device for offline replay after reconnection.

5. Offline Mode and Local Storage

Even without an active internet connection, Sudo allows users to:

• View previously received messages stored locally via Drift DB (Flutter SQLite wrapper).

• Continue composing messages for queued sending upon reconnection.

• Automatically resync with the Redis queue to fetch any missed messages once back online.

6. Server Scaling Strategy

The real-time infrastructure supports tiered horizontal scaling:

• Messaging API Layer: WebSocket load balancers distribute traffic across multiple server instances.

• Redis Broker Layer: Redis Clusters scale horizontally to handle high publish/subscribe throughput.

• Storage Layer: PostgreSQL scales via partitioning and sharding for user and metadata storage.

• Local Cache Layer: Drift DB remains client-side only, ensuring no dependency bottlenecks.

7. Load Performance Benchmarks

• Successfully tested 100,000+ concurrent WebSocket connections with Ably as a fallback relay.

• Achieved sub-100ms delivery latency for 95% of messages.

• Baseline infrastructure supports 1 million messages per day with capacity to scale further as adoption grows.