← Bitgo Interview Insights

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

SeniorPrefer not to say
Jun 2026

Summary

System design round at BitGo for a software engineer role. One massive question that basically asked you to justify every architectural decision you'd ever make at scale. Felt more like a written exam than a conversation.

Questions Asked (1)

Q1

For a web-scale service handling something like 20k QPS with P99 latency under 200ms and 99.99% availability, walk through the tradeoffs across monolith vs microservices, relational vs document vs wide-column databases, synchronous RPC vs event-driven messaging, REST vs gRPC, various caching strategies, strong vs eventual consistency, partitioning strategies, and load balancing approaches. For each, give a concrete scenario, justify your choice, and explain the implications for latency, availability, cost, operability, and failure modes.

System DesignTechnical Trade-offsData Modeling
Author's notes

This question is basically eight questions crammed into one.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the workload characteristics (read/write ratio, data size, access patterns) and then systematically compare each trade-off against the given SLOs (20k QPS, P99 <200ms, 99.99% availability). For each choice, provide a concrete scenario, justify it, and explicitly discuss implications for latency, availability, cost, operability, and failure modes.

Pro tip: Anchor every trade-off to the SLOs and emphasize that 99.99% availability (52 minutes downtime/year) demands redundancy and graceful degradation at every layer. Show maturity by acknowledging that the 'right' answer depends on context and that hybrid approaches are often best.

1. Clarify Requirements and Assumptions

Ask about read/write ratio, data volume, consistency needs, and geographic distribution. State assumptions like 20k QPS mostly reads, data size in TBs, and global user base.

2. Evaluate Architecture: Monolith vs Microservices

Compare monolith (simpler ops, lower latency, but scaling and fault isolation challenges) vs microservices (independent scaling, fault isolation, but network overhead and operational complexity). Choose based on team size and domain complexity.

3. Select Data Stores and Consistency Models

For each data type, choose relational (strong consistency, complex queries), document (flexible schema, horizontal scaling), or wide-column (high write throughput, tunable consistency). Discuss strong vs eventual consistency and their impact on latency and availability.

4. Design Communication and Caching

Decide between synchronous RPC (REST/gRPC) for low-latency, strongly consistent calls and event-driven messaging for decoupling and resilience. Choose caching strategies (client, CDN, application, database) based on data volatility and access patterns.

5. Plan Partitioning and Load Balancing

Choose partitioning strategy (hash, range, geo) to distribute load and enable scalability. Select load balancing approach (L4 vs L7, global vs local) to meet latency and availability goals, considering health checks and failover.

Key Points to Mention

  • Monolith vs microservices: trade-offs in latency, fault isolation, operational complexity, and team autonomy.
  • Database choices: relational (ACID, joins), document (flexible schema, horizontal scaling), wide-column (high write throughput, tunable consistency).
  • Synchronous RPC vs event-driven: latency vs resilience, coupling, and failure modes (e.g., retries, idempotency).
  • REST vs gRPC: gRPC for internal low-latency, high-throughput; REST for external simplicity and compatibility.
  • Caching strategies: CDN for static assets, Redis for session/data caching, cache invalidation and consistency challenges.
  • Consistency models: strong (higher latency, lower availability) vs eventual (lower latency, higher availability) and their impact on user experience.
  • Partitioning: hash for even distribution, range for range queries, geo for data locality; rebalancing and hot spots.
  • Load balancing: L4 vs L7, global server load balancing (GSLB) for geo-distribution, health checks and failover.

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