# Design a Mobile Encrypted Messenger: Signal-Style End-to-End

Source: https://www.techinterview.org/post/3233475338/mobile-system-design-encrypted-messenger-signal-style/
Updated: 2026-07-12 · techinterview.org

"Design Signal" or "design an E2E messenger" is a senior+ mobile-system-design prompt that probes whether you understand modern cryptography, multi-device key management, and the unique product-engineering choices that come from a "we cannot read your messages" guarantee. The interview is not a cryptography exam. It tests whether you can reason about the system design with crypto as a constraint.

## Clarify scope

- 1:1 messages only or group chats?

- Voice / video calls in scope?

- Multi-device (phone + desktop) sync?

- Stories / disappearing messages?

- Backups (encrypted, optional)?

## Core cryptography to know

- The Signal Protocol uses X3DH for initial key agreement and the Double Ratchet for ongoing forward and post-compromise security.

- Sealed sender hides who sent each message from the server (Signal-specific).

- Group chats use Sender Keys, with per-member key rotation.

- Safety numbers are the per-conversation fingerprint users compare to verify identity.

You do not need to implement these in the interview, but you should be able to articulate what they protect against.

## Server's role

The server stores ciphertext and routes it. It does not see plaintext. Its responsibilities:

- Pre-key bundle distribution (initial key exchange)

- Encrypted message queue per recipient

- Push notification fanout (without revealing content)

- Account registration via phone number / username

- Relay for voice/video signaling (TURN servers for media)

Minimize server knowledge. No social graph, no plaintext metadata, ideally no IPs (Tor / proxy support).

## Multi-device: the hard part

Signal's original design was single-device. Multi-device added significant complexity:

- Each device has its own identity key

- Linking a new device transfers state via a QR-coded ephemeral key

- Messages must be encrypted separately per recipient device

- Sender's old devices need to receive their own outgoing messages (so all your devices show your sent messages)

- Group state must include all members' devices

Result: a 5-person group with 3 devices each = 15 ciphertexts per outgoing message. The protocol handles this; the client must orchestrate the encryption.

## Key management on device

- Identity key in OS keychain (Secure Enclave / Keystore)

- Pre-keys generated in batches, uploaded to server (one-time use for first message from a stranger)

- Session ratchet state encrypted at rest in app database

- Database itself encrypted with a key derived from a passphrase or biometric

## Push notifications

- Server sends an encrypted push payload

- Notification extension (iOS Notification Service Extension; Android: app handles via FCM data message) decrypts on the device

- OS displays the decrypted preview

- Server never sees the plaintext sender or message body

Sealed sender in Signal hides the sender from the server even at the routing layer.

## Voice and video

- WebRTC for media; SRTP for end-to-end encryption

- Signaling over the encrypted message channel (so even the call setup is private)

- TURN server for NAT traversal, handles encrypted traffic blind

- Group calls use SFU but with end-to-end-encrypted media (Signal's SFU does not see plaintext)

## Disappearing messages

- Per-conversation timer (e.g., 24 hours)

- Each message includes a TTL; receiver's app deletes locally after expiry

- Server cannot enforce; relies on receiver's client

- Screenshots, screen recording, screen sharing all out of scope of the protocol; design with a realistic threat model

## Backups

- Optional, off by default in Signal

- Encrypted with a 30-digit recovery code

- Stored in iCloud / Google Drive / file

- Tradeoff: convenience vs single-point-of-compromise

## Account model

- Signal: phone number registration; usernames now layered on top

- Other E2E messengers: account-based (Wire) or username-based (Threema)

- Phone-based has UX advantages (auto-discovery) and privacy disadvantages

## Metadata minimization

- Server learns: "X is online", "X received N messages today"

- Server should not learn: who X talks to, how often, or what was said

- Some leaks are inevitable (timing, sizes); design to minimize

## Performance considerations

- Initial sync after fresh install: download ciphertext history (limited; Signal does not back up by default)

- Database scales with conversation history; periodic cleanup of stale ratchet state

- Battery: balance push-driven wakeups against keeping a socket open for active conversations

## What separates senior from staff

Senior candidates draw the client-server split with server-as-relay. Staff candidates discuss the multi-device fanout cost, sealed sender / metadata minimization, and the threat model of disappearing messages. Principal candidates raise the post-quantum migration story (PQXDH, the new Signal Protocol upgrade).

## Frequently Asked Questions

### Should I implement my own crypto?

No. Use libsignal (Signal's own library) or Olm/Megolm (Matrix) or Wire's Proteus. Custom crypto fails subtly. Show that you know not to roll your own.

### How does iMessage compare?

iMessage is E2E for blue-bubble-to-blue-bubble; uses a Signal-like protocol since 2024. Multi-device handled differently (Apple ID-tied).

### What about Telegram?

Cloud chats are not E2E by default; Secret Chats are E2E but device-bound. Worth mentioning the difference between "encrypted in transit" and "end-to-end encrypted."