Lyft·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

May 2026

Summary

Lyft system design round for a software engineer role. The question was a full-on real-time chat system design covering basically everything you could think of, and I mean everything. Left feeling like I'd only scratched the surface on half the topics.

Questions Asked (1)

Design a scalable real-time chat system that supports both 1:1 and group messaging. Walk through API design, message ordering, read receipts, online presence, storage, sharding, consistency trade-offs, offline delivery, rate limiting, encryption, capacity estimates for 100M DAU, and observability.

System DesignTechnical Trade-offsData Modeling

Author's notes

This was basically a 45-minute gauntlet.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale (100M DAU, 1:1 and group messaging, real-time, offline delivery) and then walk through the design in a structured manner: API design, data model and storage, message flow and ordering, presence and read receipts, sharding and consistency, rate limiting, encryption, capacity estimation, and observability. Emphasize trade-offs at each step, especially consistency vs. availability, and how you would handle failures and scale.

Pro tip: Proactively discuss how you would handle message ordering and idempotency in a distributed system, and tie it back to Lyft's need for reliable real-time communication. Also, mention that you would start with a simple design and iterate based on bottlenecks, showing you can prioritize.

1. Clarify Requirements and Scale

Ask clarifying questions to understand functional and non-functional requirements: 1:1 and group messaging, message ordering, read receipts, online presence, offline delivery, encryption, and scale (100M DAU). Estimate QPS, storage, and bandwidth to ground the design.

2. High-Level Architecture and API Design

Propose a high-level architecture with clients, WebSocket gateways, chat servers, message queues, and storage. Define key APIs for sending messages, fetching history, and managing groups, using REST for management and WebSocket for real-time.

3. Data Model, Storage, and Sharding

Design the data model for users, conversations, messages, and receipts. Choose storage solutions (e.g., Cassandra for messages, Redis for presence) and sharding strategy (e.g., by conversation ID or user ID) to ensure scalability and low latency.

4. Message Flow, Ordering, and Delivery Guarantees

Explain how messages are routed, ordered (using sequence numbers or timestamps), and delivered reliably. Discuss offline delivery via push notifications and message queues, and how to handle read receipts and presence updates.

5. Trade-offs, Security, and Observability

Discuss consistency trade-offs (e.g., eventual consistency for presence, stronger for messages), rate limiting, end-to-end encryption, and observability (metrics, logging, tracing). Also cover capacity estimates and how to monitor and scale the system.

Key Points to Mention

Use WebSockets for real-time bidirectional communication and a message queue (e.g., Kafka) for reliable delivery and decoupling.
Shard messages by conversation ID to ensure ordering within a conversation and distribute load evenly.
Implement read receipts and presence using a lightweight store like Redis with pub/sub for updates, accepting eventual consistency.
For offline delivery, store undelivered messages and use push notifications (APNs/FCM) when the user comes online.
Apply rate limiting per user and per IP to prevent abuse, and use end-to-end encryption for message content.
Estimate capacity: 100M DAU, assume 50 messages/user/day => 5B messages/day, ~58K messages/sec average, peak 3x. Storage: 5B * 1KB = 5TB/day.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.