Problem and Scope
Design a stock trading application similar to Robinhood that allows users to view real-time stock information, make trades, and manage their portfolios.
Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Users should be able to view real-time stock prices and market data
- Users should be able to place buy/sell orders for stocks
- Users should be able to view their current positions and transaction history
- The system should display accurate price information aggregated from multiple exchanges
- The system should provide real-time updates as stock prices change
- Users should be able to manage their portfolios and track performance
Non-functional requirements:
- Low latency for displaying real-time market data (ideally under 500ms)
- High availability for the trading platform (99.9%+ uptime)
- Scalability to handle millions of concurrent users
- Data consistency for user transactions and account balances
- Security measures to protect financial transactions and user data
- Fault tolerance to handle component failures without affecting the entire system
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- 100 million users
- Approximately 100 stocks per user on average
- Thousands of stock symbols to track
- Multiple exchanges providing market data
- Millions of concurrent connections during market hours
- Spikes in traffic during market open/close and major financial events
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- Real-time market data ingestion system
- Order processing system
- User portfolio management
- Authentication and authorization
- Data storage for user profiles, transactions, and positions
- Market data processing and aggregation
- Client applications (mobile, web)
- Notification system
- Aggregating market data from multiple exchanges to determine the best price
- Managing high volume of real-time data while maintaining low latency
- Ensuring system reliability during peak trading periods
- Optimizing client-server communication to minimize battery and data usage
- Implementing fault tolerance for critical components
- Scaling the system to handle millions of concurrent users
- Providing a consistent experience across different client devices
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How will you aggregate data from multiple exchanges to provide accurate pricing?
- Focus: Assess the candidate's answer to "How will you aggregate data from multiple exchanges to provide accurate pricing" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What's your strategy for minimizing the load on client devices while providing real-time updates?
- Focus: Assess the candidate's answer to "What's your strategy for minimizing the load on client devices while providing real-time updates" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your system handle fault tolerance at the exchange layer?
- Focus: Assess the candidate's answer to "How would your system handle fault tolerance at the exchange layer" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What approach would you take to scale the system as the number of users increases?
- Focus: Assess the candidate's answer to "What approach would you take to scale the system as the number of users increases" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would you optimize the communication between different components?
- Focus: Assess the candidate's answer to "How would you optimize the communication between different components" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What measures would you implement to ensure data consistency for user transactions?
- Focus: Assess the candidate's answer to "What measures would you implement to ensure data consistency for user transactions" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to view real-time stock prices and market data; Users should be able to place buy/sell orders for stocks; Users should be able to view their current positions and transaction history. Establishes the constraints that materially affect Design Robinhood, including Low latency for displaying real-time market data (ideally under 500ms); High availability for the trading platform (99.9%+ uptime). Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Real-time market data ingestion system; Order processing system; User portfolio management; Authentication and authorization. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as 100 million users; Approximately 100 stocks per user on average to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Real-time market data ingestion system; Data storage for user profiles, transactions, and positions; Market data processing and aggregation. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Ensuring system reliability during peak trading periods; Providing a consistent experience across different client devices; High availability for the trading platform (99.9%+ uptime). Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Implementing fault tolerance for critical components; Scaling the system to handle millions of concurrent users; Providing a consistent experience across different client devices. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.