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

SeniorPrefer not to say

May 2026

Summary

System design round at Upstart for a software engineer role. The whole thing was basically one big question about building a chat system from scratch, which sounds manageable until you realize how many layers they actually want you to cover.

Questions Asked (1)

Design a real-time chat application similar to Slack or WhatsApp. Walk through functional requirements, non-functional requirements, APIs, and the high-level architecture.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

This is a lot more surface area than it looks.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying scope and scale (e.g., 1:1 vs group chats, expected DAU, message volume) to tailor the design. Then systematically cover functional and non-functional requirements, define key APIs, and sketch a high-level architecture with clear data flow and trade-offs. Emphasize real-time delivery, reliability, and scalability.

Pro tip: Proactively discuss trade-offs (e.g., WebSockets vs. long polling, SQL vs. NoSQL for messages) and tie them to Upstart's need for reliability and low-latency in a fintech context. Mention monitoring and observability early to show production maturity.

1. Clarify Requirements and Scale

Ask questions to understand scope: 1:1 vs group chats, message history, media support, online presence, expected DAU, peak concurrent users, and latency targets. This ensures the design meets actual needs.

2. Define Functional and Non-Functional Requirements

List core features (send/receive messages, group chats, read receipts, presence) and non-functional needs (low latency, high availability, scalability, security, consistency). Prioritize them based on business impact.

3. Design APIs and Data Model

Outline key APIs (e.g., WebSocket for real-time, REST for history) and data storage choices (e.g., Cassandra for messages, Redis for presence). Specify message schema and indexing for efficient retrieval.

4. Sketch High-Level Architecture

Draw components: clients, load balancers, WebSocket servers, message queues, databases, cache, and notification services. Explain message flow from sender to receiver, including offline handling and fan-out for groups.

5. Discuss Trade-offs and Scalability

Address bottlenecks (e.g., WebSocket connection limits), scaling strategies (horizontal scaling, sharding), and trade-offs (consistency vs. availability, push vs. pull). Mention monitoring and failure recovery.

Key Points to Mention

Use WebSockets for real-time bidirectional communication, with fallback to long polling for compatibility.
Employ a message queue (e.g., Kafka) to decouple message ingestion from delivery and ensure reliability.
Store messages in a distributed database like Cassandra for high write throughput and scalability.
Implement presence and typing indicators using a fast in-memory store like Redis with pub/sub.
Design for offline users: store undelivered messages and push notifications via APNs/FCM.
Ensure security: end-to-end encryption, authentication (JWT), and rate limiting to prevent abuse.

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