PM SYSTEM DESIGN FRAMEWORK: Design a Real-Time Messaging Platform for Enterprise with End-to-End Encryption

Overview

This framework addresses designing an enterprise-grade, real-time messaging platform with end-to-end encryption (E2EE). The system targets business users requiring secure, reliable communication while maintaining compliance and productivity features.

PHASE 1: CLARIFYING QUESTIONS (5-7 minutes)

Product Scope:

• Are we designing the full platform (messaging, calls, file sharing) or focusing on core text messaging first?
• What’s the primary use case: team collaboration, customer support, or executive communication?
• Are we competing with Slack/Teams or with Signal/WhatsApp for enterprise?

Scale Assumptions:

• What’s the target organization size: SMBs (10-100), mid-market (100-1,000), or enterprise (1,000+)?
• Expected number of messages per user per day?

Encryption Specifics:

• Who holds the encryption keys: users, organization admins, or platform?
• Do we need searchable message history with E2EE (complex trade-off)?
• Do admins need any visibility for compliance/eDiscovery?

PHASE 2: USER NEEDS & PERSONAS (5 minutes)

Persona 1: End User (Employee/Team Member) - 80% of users

• Need: Fast, reliable messaging that works across devices
• Need: Confidence that sensitive conversations are private
• Job: “I need to communicate securely without thinking about encryption”

Persona 2: IT Administrator - 5% of users, high influence

• Need: Centralized control over security policies
• Need: Compliance reporting and audit trails
• Job: “I need to ensure communications meet compliance requirements”

Persona 3: Security/Compliance Officer - 1%, critical stakeholder

• Need: Proof that data is encrypted and meets regulatory standards
• Need: Ability to respond to legal/compliance requests
• Job: “I need to prove to auditors our communications are secure and compliant”

PHASE 3: HIGH-LEVEL ARCHITECTURE (10-15 minutes)

[Mobile App] <-> [API Gateway] <-> [Backend Services]
                      |                     |
                 [TLS/HTTPS]    +-----------+-----------+
                                |           |           |
                          [Message    [Identity &   [Admin
                           Routing]    User Service] Portal]
                              |             |           |
                         [Message      [User DB]   [Policies,
                          Storage]    (metadata)   Reporting]
                         (encrypted)

[Client-Side Encryption (E2EE)]
- Key generation and exchange handled on devices
- Server only sees encrypted message blobs

Key Components (PM Level):

Client Applications: Native apps handling encryption/decryption locally

• Why: E2EE requires client-side key management; server never sees plaintext
• PM Consideration: UX must hide complexity; key sync across devices is critical

Message Routing Service: Routes encrypted messages in real-time

• Why: Enables instant delivery without decrypting content
• PM Consideration: Latency here affects UX directly

What NOT to Discuss:

• Specific encryption algorithms (Signal Protocol, AES-256)
• WebSocket vs long-polling implementation
• Database schema for message tables
• Load balancer configuration

PHASE 4: KEY TRADE-OFFS (10-15 minutes)

Trade-off 1: User-Controlled Keys vs Admin Recovery

• Options: User-only keys (Signal) | Admin-escrowed keys | Hybrid with opt-in escrow
• PM Reasoning: True E2EE means even we can’t read messages, which enterprises love for security but hate for compliance. Regulated industries often require eDiscovery.
• Recommendation: Hybrid - default to user-only keys; allow opt-in admin escrow for specific channels with explicit user notification
• Impact: Meets compliance while building trust through transparency

Trade-off 2: Searchable Message History vs E2EE

• Options: Full client-side search | No search | Metadata search only
• PM Reasoning: Search is #1 productivity feature, but E2EE means server can’t index content
• Recommendation: Metadata search (sender, date, file names) server-side + progressive client-side content search for recent messages
• Impact: 80% of searches covered; better than no search (Signal)

Trade-off 3: Real-Time Delivery vs Battery/Data Efficiency

• Options: Always-on persistent connections | Push notifications + fetch | Adaptive
• Recommendation: Adaptive - persistent when active, push when backgrounded
• Impact: 40-60% reduction in battery vs always-on; acceptable latency

PHASE 5: SCALING CONSIDERATIONS (5-10 minutes)

User Growth (1K to 1M users):

• Challenge: Connection management and message routing complexity
• Approach: Regional API gateways; WebSocket connection pooling
• Trade-off: Infrastructure cost increases linearly but latency stays low

Geographic Expansion:

• Challenge: Message delivery latency across continents, data residency
• Approach: Regional data centers with message routing; data residency controls per org
• Trade-off: Higher cost; complexity in cross-region delivery

PHASE 6: SUCCESS METRICS (5-7 minutes)

Primary Metrics:

• DAU/MAU ratio (engagement health)
• Messages Sent per Active User per Day (target: 50-100)
• Organizational Retention (target: >90% annual)

Technical Health:

• Message Delivery Latency p95 (target: <2 seconds)
• Delivery Success Rate (target: >99.9%)

Trade-off Monitoring:

• Battery Drain per Hour (benchmark vs competitors)
• Admin Support Tickets (key recovery, access requests)

PM vs SWE DEPTH COMPARISON

PM Answer (Just Right):
“When users first connect, their devices generate encryption keys locally. The server coordinates key exchange without ever seeing the keys. If a user loses all devices, we can’t recover history unless they opted into admin escrow. We’d measure success by key exchange success rate and support tickets for recovery.”

Too SWE (Too Deep):
“We’d implement X3DH key agreement with Curve25519. Each client generates an identity key pair and signed prekeys. We’d use Double Ratchet for forward secrecy with AES-256-GCM and HMAC-SHA256.”

The Difference: PM answer shows understanding, focuses on user impact and trade-offs, mentions metrics. SWE answer dives into implementation details.

INTERVIEW TIPS

Strong PM Signals:

• Recognizing tension between E2EE and enterprise requirements
• Asking about compliance requirements upfront
• Distinguishing what server can/cannot see in E2EE
• Framing technical decisions as product trade-offs

Red Flags:

• Diving into encryption algorithms
• Ignoring enterprise context
• Not addressing E2EE trade-offs (search, recovery, compliance)

Time Management (45 min):
5 min clarifying, 5 min personas, 10 min architecture, 10 min trade-offs, 5 min scaling, 5 min metrics, 5 min buffer

PRACTICE QUESTIONS

• Easier: Design E2EE file sharing for existing messaging platform
• Same level: Design Slack with end-to-end encryption
• Harder: Design secure messaging for government/military use

Framework Generated by: PM System Design Framework Generator