Problem
You are designing the data layer for a financial trading platform. Different parts of the system have different consistency requirements. Your task is to analyze each subsystem, determine the appropriate consistency model, and design the architecture that supports both strong and eventual consistency where needed.
The Trading Platform Subsystems
- Account Balance: The current cash balance of each trading account. Used to validate whether a user can place a trade.
- Order Book: The list of all active buy and sell orders for each stock. Matched in real-time to execute trades.
- Trade History: The historical record of all executed trades. Used for compliance reporting and tax calculations.
- Portfolio View: A user's current holdings (stocks and quantities). Displayed on the dashboard.
- Market Data Feed: Real-time stock prices from external exchanges. Updates every 100ms per stock.
- Leaderboard: A ranking of top-performing traders by return percentage. Updated periodically.
- Notification Preferences: User settings for email, push, and SMS notifications.
Decision Framework
For each subsystem, analyze:
- What happens if a user reads stale data? (Mild inconvenience? Financial loss? Legal violation?)
- What is the write throughput? (Updates per second)
- What is the read/write ratio? (Read-heavy? Write-heavy? Balanced?)
- What is the acceptable staleness window? (0ms? 100ms? 5 seconds? 1 hour?)
- Are there cross-system consistency requirements? (Must balance and orders agree?)
Your Task
- Classify each subsystem as requiring strong consistency, eventual consistency, or a hybrid.
- Justify each classification using the decision framework.
- Design the data architecture showing which databases and replication strategies to use.
- Handle the boundary cases where strongly consistent and eventually consistent systems interact.
- Explain how the CAP theorem constrains your choices during network partitions.
Constraints
- The platform must comply with financial regulations (accurate balance reporting).
- Trades must execute correctly (no double-spending of the same balance).
- The system spans two data centers for disaster recovery.
- Peak load: 10,000 trades per second, 100,000 concurrent users.
- Latency budget for trade execution: under 50ms end-to-end.