[ OK ]4d1e2b58-798d-4721-9183-c8d8b21c7348 — full content available
[ INFO ]category: System Design difficulty: unknown freq: first seen: 2026-03-13
[UNKNOWN][SYSTEM DESIGN]
$catproblem.md
For a Databricks interview, a "Stock Trading Agent" problem typically appears in the System Design or Machine Learning Engineering rounds. It focuses on architecting a platform that can handle high-frequency data ingestion, real-time trading decisions, and reliable execution.
Problem Statement Overview
Design a service for a stock trading platform (similar to Robinhood or Zerodha) that allows users or automated agents to interact with a stock exchange. YouTube +1 0
1. Core Functional Requirements
Order Placement: Enable users or agents to place buy and sell orders (market and limit orders).
Real-time Market Data: Provide users with highly available, real-time stock price updates.
Historical Data: Serve time-series data (charts/candles) for informed decision-making or model training.
Consistency: Ensure high consistency for financial transactions (e.g., money is only deducted if the trade is executed). YouTube +4
2. Technical Challenges (The "Interview" Focus)
Atomic Transactions: How to ensure trade execution and portfolio updates are atomic and resilient to failure.
Exactly-Once Processing: How to prevent double-spending or duplicate order fulfillment under high contention.
Scalability: Handling millions of users and high-throughput market data with sub-100ms latency.
Data Isolation: Separating the low-latency trading path from heavy analytical/historical data workloads. Hello Interview +2
3. Databricks-Specific Considerations
If this is for a Databricks role, expect to discuss how you would use their ecosystem to solve these:
Delta Lake: Using Delta Lake for ACID transactions and "time travel" to debug historical trade failures.
Structured Streaming: Implementing Spark Structured Streaming to process real-time market ticks into Gold-layer tables.
MLflow: Managing the lifecycle of the trading "agent" (ML model) using MLflow for experiment tracking and deployment.
Unity Catalog: Governing access to sensitive financial data across different teams. WeCP +3
Potential Coding Follow-up
You may be asked to implement a Rate Limiter or a Request Tracker using a sliding window or a double-ended queue (deque) to maintain a specific time window (e.g., last 5 minutes) of requests. Medium +1 3
Would you like to walk through a high-level system architecture or focus on the coding implementation for the rate limiter?