Design Mobile Chat Client Architecture

1. Problem Statement & Scope

System Mission

Design a battery-optimized, ultra-responsive, offline-resilient mobile chat client architecture managing bidirectional persistent WebSocket connections, encrypted local SQLite storage (SQLCipher), end-to-end encryption (E2EE Signal Protocol / Double Ratchet), binary Protocol Buffers serialization, and silent background push synchronization.

Interactive Architecture Diagram
100%Fit100%
Synthesizing vector architecture diagram...

Functional Requirements

1. Real-Time 1:1 and Group Chat: Send and receive text, media pointers, reactions, and threaded replies over low-latency WebSockets.
2. Offline-First Messaging & Local Outbox: Messages authored offline are immediately rendered in the UI with a "clock" icon, committed to local SQLite, and dispatched sequentially upon reconnection.
3. Delivery & Read Receipts: Real-time multi-state message tracking (SENDING $\to$ SENT_TO_SERVER $\to$ DELIVERED_TO_DEVICE $\to$ READ_BY_RECIPIENT).
4. End-to-End Encryption (E2EE): Implement Double Ratchet (Signal Protocol) cryptographic session state with private keys stored in hardware keystores.
5. Silent Push Background Synchronization: Receive background pushes (content-available: 1), waking the app for 30s to decrypt and store incoming messages in SQLite prior to user interaction.

Non-Functional Requirements (SLAs/SLOs)

• Send-to-Display Latency: $< 100\text{ ms}$ on 4G/5G; instant $0\text{ ms}$ optimistic local UI rendering.
• Battery & Radio Overhead: $< 2\%$ total device battery consumption per day for background presence.
• Local Database Encryption: Full AES-256 encryption at rest (zero plaintext leakage in flash memory).
• Wire Payload Efficiency: $\ge 80\%$ payload size reduction via binary Protocol Buffers vs standard JSON.
• Reconnection Recovery: Automatic session resumption in $< 300\text{ ms}$ after transient connection drop.

Out-of-Scope

• Voice/Video calling media streaming (WebRTC RTP/RTCP transport pipelines covered in dedicated VoIP blueprints).
• Complex channel broadcast feeds with $> 100,000$ concurrent subscribers.

2. Capacity & Scale Estimation

Device & Traffic Scale

• Mobile Active Installs: $100\text{ Million}$ devices ($30\text{ Million}$ DAU).
• Concurrent Connected Sockets: Peak $10\text{ Million}$ simultaneous WebSocket connections during peak hours.
• Daily Messages Processed: $500\text{ Million}$ messages/day. $\text{Average Message QPS} = \frac{500 \times 10^6}{86,400 \text{ s}} \approx 5,787 \text{ msgs/s (Peak: } 20,000\text{ msgs/s)}$

Bandwidth & Serialization Efficiency

• Serialization Comparison:
  • Standard JSON Frame: $\approx 450\text{ Bytes}$ (message_id, conversation_id, sender_id, recipient_id, timestamp, body, signature).
  • Optimized Protobuf Binary Frame: $\mathbf{75\text{ Bytes}}$ ($83.3\%$ bandwidth reduction). $\text{Daily Client Network Egress (Protobuf)} = 500 \times 10^6 \times 75\text{ Bytes} = \mathbf{37.5\text{ GB/day}}$ $\text{Daily Client Network Egress (JSON)} = 500 \times 10^6 \times 450\text{ Bytes} = \mathbf{225\text{ GB/day}}$
• Heartbeat Bandwidth: 10M connected clients sending a $2\text{ Byte}$ ping every 60s $\implies \frac{10^7 \times 2\text{ B}}{60\text{ s}} \approx 333\text{ KB/s} \approx \mathbf{2.67\text{ Mbps}}$.

3. High-Level Architecture & AWS Component Mapping

Interactive Architecture Diagram
100%Fit100%
Synthesizing vector architecture diagram...

Component Responsibility Breakdown

4. API Interface Design & Protobuf Message Schema

1. Protocol Buffers Wire Schema (chat_protocol.proto)

protobufCopy
syntax = "proto3";
package chat.mobile.v1;

enum DeliveryStatus {
  STATUS_UNKNOWN = 0;
  SENDING = 1;
  SENT_TO_SERVER = 2;
  DELIVERED = 3;
  READ = 4;
}

message ChatMessageFrame {
  string message_id = 1;
  string conversation_id = 2;
  string sender_id = 3;
  int64 timestamp_ms = 4;
  DeliveryStatus status = 5;
  bytes encrypted_payload = 6;      // Double Ratchet encrypted ciphertext
  bytes ephemeral_public_key = 7;   // Ratchet ephemeral key (32 bytes)
  int32 ratchet_counter = 8;
  bytes hmac_auth_tag = 9;
}

message ReceiptBatchFrame {
  string conversation_id = 1;
  DeliveryStatus status = 2;
  repeated string message_ids = 3;
  int64 receipt_timestamp_ms = 4;
}

2. WebSocket Frame Envelope

jsonCopy
{
  "action": "send_message",
  "payload_base64": "Cg9tc2dfOTk4MTI0YTg3YzESCGNvbnZfMTAxEgh1c3JfMjAyGICAkL21sTIy..."
}

5. Data Models & Storage Architecture

Interactive Architecture Diagram
100%Fit100%
Synthesizing vector architecture diagram...

Local SQLCipher Schema (chat_encrypted_storage.db)

sqlCopy
-- Encrypted Conversations Table
CREATE TABLE conversations (
    conversation_id TEXT PRIMARY KEY,
    peer_user_id TEXT NOT NULL,
    last_message_id TEXT,
    unread_count INTEGER NOT NULL DEFAULT 0,
    updated_at INTEGER NOT NULL
);

-- Encrypted Local Messages Table
CREATE TABLE local_messages (
    message_id TEXT PRIMARY KEY,
    conversation_id TEXT NOT NULL,
    sender_id TEXT NOT NULL,
    plaintext_body TEXT NOT NULL,
    delivery_status TEXT CHECK (delivery_status IN ('SENDING', 'SENT', 'DELIVERED', 'READ')),
    is_outgoing INTEGER NOT NULL, -- 1=true, 0=false
    timestamp_ms INTEGER NOT NULL
);
CREATE INDEX idx_conversation_timeline ON local_messages(conversation_id, timestamp_ms DESC);

-- Double Ratchet Cryptographic Session State
CREATE TABLE ratchet_sessions (
    conversation_id TEXT PRIMARY KEY,
    root_key BLOB NOT NULL,
    sending_chain_key BLOB NOT NULL,
    receiving_chain_key BLOB NOT NULL,
    sending_counter INTEGER NOT NULL DEFAULT 0,
    receiving_counter INTEGER NOT NULL DEFAULT 0,
    last_updated INTEGER NOT NULL
);