“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 is testing 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
- Signal Protocol: X3DH for initial key agreement; Double Ratchet for ongoing forward and post-compromise security
- Sealed sender: hide who sent each message from the server (Signal-specific)
- Group: Sender Keys for group chats, with per-member key rotation
- Safety numbers: 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 the threat model honest
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.”