Design an API for Financial Portfolio Tracking
Design a service to track a user's stock and crypto holdings. Focus on integrating with external financial data feeds and handling data staleness.
Why Interviewers Ask This
Interviewers at Stripe ask this to evaluate your ability to design systems that balance real-time accuracy with eventual consistency, a core challenge in fintech. They specifically test how you handle external data staleness from volatile markets while ensuring the user interface remains responsive. The question assesses your judgment in choosing between strong consistency and availability when integrating third-party financial APIs.
How to Answer This Question
1. Clarify requirements immediately: Define scope (stocks vs. crypto), latency needs (real-time vs. delayed), and data freshness tolerances. 2. Outline high-level architecture: Propose a service that ingests data via webhooks or polling, processes it through a message queue like Kafka, and stores it in a database optimized for time-series data. 3. Address data staleness explicitly: Discuss strategies like caching layers with TTLs, background refresh jobs, and UI indicators showing 'last updated' timestamps to manage user expectations. 4. Design for reliability: Explain how to handle API rate limits from vendors and implement retry logic with exponential backoff. 5. Conclude with trade-offs: Summarize why you chose eventual consistency over strong consistency for this specific use case, highlighting Stripe's focus on developer experience and robust infrastructure.
Key Points to Cover
- Explicitly addressing the trade-off between data freshness and system availability
- Proposing a specific caching strategy with TTLs and staleness indicators
- Designing a resilient ingestion layer that handles external API rate limits
- Selecting appropriate storage solutions like Time-Series databases for financial data
- Demonstrating awareness of Stripe's focus on reliability and developer trust
Sample Answer
To design a Financial Portfolio Tracking service, I would start by defining the core constraint: market data is inherently asynchronous. Users expect near real-time updates, but relying solely on synchronous calls to external providers like Bloomberg or CoinGecko will cause timeouts and poor UX. My approach uses an event-driven architecture. First, we ingest price feeds using a mix of WebSocket streams for active trading hours and scheduled polling for off-hours, pushing raw events into a Kafka topic. A consumer service normalizes this data and writes it to a Time-Series Database like TimescaleDB for fast historical queries, while also updating a Redis cache for the current portfolio value. To handle staleness, the system calculates a 'freshness score' based on the timestamp of the last feed update. If data exceeds a threshold, the UI displays a warning badge rather than stale numbers. We also implement idempotent writes to prevent duplicate transactions during network retries. This ensures that even if a vendor feed lags, our system remains available and transparent about data quality, aligning with Stripe's philosophy of building reliable, developer-friendly financial infrastructure.
Common Mistakes to Avoid
- Ignoring data staleness entirely and assuming all external APIs return instant, accurate data
- Failing to account for rate limits and potential downtime of third-party financial providers
- Over-engineering with strong consistency models that degrade performance unnecessarily
- Neglecting to explain how the user interface communicates data status to the end user
Practice This Question with AI
Answer this question orally or via text and get instant AI-powered feedback on your response quality, structure, and delivery.