Functional Requirements:
- "What's the primary use case - small teams or large enterprises?"
- "Do we need real-time messaging, file sharing, and integrations?"
- "Should we support threaded conversations and search?"
- "Are there specific compliance requirements (GDPR, HIPAA)?"
- "Do we need mobile apps or just web interface?"

Non-Functional Requirements:
- "What's the expected scale? How many users and workspaces?"
- "What's the acceptable message delivery latency?"
- "What are the availability requirements?"
- "Do we need global distribution?"
- "Are there specific integration requirements?"

Example Calculation:
- 10M registered users
- 20% daily active users = 2M DAU
- Peak concurrent users = 30% of DAU = 600K
- Average 50 messages per user per day
- Total daily messages = 2M × 50 = 100M messages/day
- Peak messages per second = 100M / (24 × 3600) × 3 = ~3.5K msg/sec

Storage Calculation:
- Average message size: 200 bytes
- Daily message storage: 100M × 200B = 20GB/day
- Annual message storage: 20GB × 365 = 7.3TB/year
- File uploads: 10M files/day × 1MB avg = 10TB/day

Client Apps → Load Balancer → API Gateway → Core Services
                                          ↓
                                [Message] [File] [User] [Search]
                                          ↓
                                    Database Layer

// Show understanding of fan-out patterns
"For message broadcasting, I'd use a combination of:
1. Redis pub/sub for immediate delivery to online users
2. Kafka for reliable message persistence
3. Push notifications for offline users
4. WebSocket connection management with sticky sessions"

"I'd use a polyglot persistence approach:
- PostgreSQL for user accounts, workspaces, channels (ACID compliance)
- Redis for real-time data, sessions, presence (fast access)
- Elasticsearch for message and file search (full-text search)
- S3 for file storage with CDN distribution"

"The main bottlenecks are:
1. WebSocket connection limits per server
2. Message fan-out to large channels
3. Search index updates for real-time search
4. File upload concurrency and processing

Solutions:
- Horizontal scaling with connection pooling
- Efficient message routing with Redis pub/sub
- Asynchronous search indexing
- Chunked file uploads with resumability"

1. Acknowledge the challenge: "This is a fan-out problem with potential performance issues"

2. Solution approach:
   - "Use Redis pub/sub to broadcast to WebSocket servers"
   - "Each server maintains connections for ~10K users"
   - "Batch notifications to reduce database load"
   - "Use push notifications for offline users"

3. Optimization strategies:
   - "Implement message queuing for reliability"
   - "Use connection pooling and sticky sessions"
   - "Consider read receipts and delivery confirmations"
   - "Implement rate limiting to prevent spam"

4. Monitoring: "Track delivery success rates and latency metrics"

Message Ordering Strategies:

1. Single Writer per Channel:
   - Route all messages for a channel to the same server
   - Use consistent hashing for channel assignment
   - Ensures total ordering within channels

2. Timestamp-based Ordering:
   - Use logical timestamps (Lamport clocks)
   - Include sequence numbers in messages
   - Handle clock skew with NTP synchronization

3. Database-level Ordering:
   - Use auto-incrementing sequence numbers
   - Partition messages by channel for performance
   - Maintain ordering within partitions

4. Client-side Handling:
   - Buffer out-of-order messages temporarily
   - Reorder based on timestamps/sequence numbers
   - Show loading states during reordering

Search Architecture:

1. Elasticsearch Cluster:
   - Separate indices per workspace for isolation
   - Time-based indices for large workspaces
   - Custom analyzers for better relevance

2. Indexing Pipeline:
   - Real-time indexing via Kafka consumers
   - Bulk indexing for historical data
   - Handle message edits and deletions

3. Search Features:
   - Full-text search with highlighting
   - Faceted search (by user, channel, date)
   - Autocomplete and suggestions
   - File content indexing

4. Performance Optimization:
   - Index only searchable fields
   - Use appropriate shard sizes
   - Implement search result caching
   - Pagination for large result sets

File Handling Strategy:

1. Upload Process:
   - Chunked uploads for large files
   - Direct upload to S3 with presigned URLs
   - Virus scanning and content validation
   - Thumbnail generation for images

2. Storage Architecture:
   - Multi-tier storage (hot, warm, cold)
   - Global CDN for fast access
   - Deduplication to save space
   - Encryption at rest and in transit

3. Sharing and Permissions:
   - Fine-grained access controls
   - Temporary sharing links
   - Download tracking and analytics
   - Integration with DLP policies

4. Performance Optimization:
   - Parallel chunk uploads
   - Resume capability for failed uploads
   - Intelligent caching strategies
   - Bandwidth optimization

Connection Management:

1. Connection Establishment:
   - Authenticate user with JWT token
   - Subscribe to user's channels and DMs
   - Set up heartbeat mechanism
   - Store connection metadata

2. Scaling Connections:
   - Load balance with sticky sessions
   - Use consistent hashing for user affinity
   - Implement connection pooling
   - Handle server failures gracefully

3. Message Routing:
   - Maintain user-to-server mapping
   - Use Redis pub/sub for cross-server communication
   - Implement message queuing for reliability
   - Handle offline users with push notifications

4. Connection Lifecycle:
   - Detect disconnections quickly
   - Implement exponential backoff for reconnections
   - Clean up resources on disconnect
   - Sync missed messages on reconnect

Presence System:

1. Status Tracking:
   - WebSocket heartbeat every 30 seconds
   - Update Redis with user status
   - Set TTL for automatic cleanup
   - Handle multiple device connections

2. Status Broadcasting:
   - Publish status changes to interested users
   - Use efficient fan-out for large teams
   - Batch status updates to reduce load
   - Implement status change debouncing

3. Offline Detection:
   - Missed heartbeat detection
   - Graceful degradation for network issues
   - Last seen timestamp tracking
   - Custom status messages with expiry

4. Cross-device Synchronization:
   - Aggregate status across devices
   - Priority-based status resolution
   - Sync status changes in real-time
   - Handle device-specific statuses

Consistency Strategies:

1. Event-Driven Architecture:
   - Use Kafka for reliable event streaming
   - Implement event sourcing for audit trail
   - Handle duplicate events with idempotency
   - Use saga pattern for distributed transactions

2. Database Consistency:
   - ACID transactions for critical operations
   - Eventual consistency for non-critical data
   - Use distributed locks when needed
   - Implement compensation actions

3. Cache Consistency:
   - Cache-aside pattern for most data
   - Write-through for critical updates
   - Use cache invalidation strategies
   - Handle cache stampede scenarios

4. Cross-service Communication:
   - Synchronous calls for immediate consistency
   - Asynchronous events for eventual consistency
   - Circuit breakers for fault tolerance
   - Retry mechanisms with exponential backoff

Mobile Optimization Strategy:

1. Data Usage Optimization:
   - Compress messages and images
   - Implement smart sync (WiFi vs cellular)
   - Use delta sync for message updates
   - Optimize API payload sizes

2. Battery Life Optimization:
   - Reduce WebSocket heartbeat frequency
   - Batch network requests
   - Use push notifications instead of polling
   - Implement background sync limits

3. Performance Optimization:
   - Local message caching
   - Lazy loading of message history
   - Image thumbnail generation
   - Offline-first architecture

4. User Experience:
   - Progressive loading of content
   - Optimistic UI updates
   - Intelligent prefetching
   - Adaptive quality based on connection

Monitoring and Observability:

1. Application Metrics:
   - Message delivery latency (P50, P95, P99)
   - WebSocket connection success rate
   - API response times
   - Error rates by endpoint

2. Infrastructure Metrics:
   - Server CPU, memory, disk usage
   - Database query performance
   - Cache hit rates
   - Network bandwidth utilization

3. Business Metrics:
   - Daily/monthly active users
   - Message volume and growth
   - Feature adoption rates
   - User engagement metrics

4. Alerting and Debugging:
   - Real-time alerts for critical issues
   - Distributed tracing for request flows
   - Log aggregation and analysis
   - Performance profiling tools

Phase 1: Basic messaging (single server)
Phase 2: Add real-time features (WebSocket)
Phase 3: Scale horizontally (multiple servers)
Phase 4: Add advanced features (search, files)
Phase 5: Global distribution and optimization

Instead of: "I'll use Redis for caching"
Say: "I'll use Redis for session storage because:
- Sub-millisecond latency for real-time features
- Built-in pub/sub for message broadcasting
- Automatic expiration for session cleanup
- High availability with Redis Cluster"

WebSocket vs Server-Sent Events:
"WebSocket provides bidirectional communication needed for typing indicators
and real-time collaboration, but SSE would be simpler for read-heavy
use cases. Given our requirements for interactive messaging, WebSocket
is the better choice despite the added complexity."

Production Considerations:
- Deployment strategy (blue-green, canary)
- Monitoring and alerting setup
- Backup and disaster recovery
- Security and compliance requirements
- Cost optimization strategies

Scaling Bottlenecks:
- "WebSocket connections are limited per server"
- "Message fan-out becomes expensive for large channels"
- "Search indexing can lag behind message creation"
- "File uploads can overwhelm storage systems"

Solutions for each bottleneck with specific numbers and techniques