← Google Interview Insights

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

SeniorPrefer not to say
May 2026

Summary

System design round at Google focused entirely on distributed transactions, which sounds manageable until you realize they want you to compare three different coordination patterns and reason through failure modes in real time. Tough session, lots of follow-ups.

Questions Asked (1)

Q1

Design a distributed transactions protocol that coordinates updates across multiple services or databases. Walk through two-phase commit, three-phase commit, and the Saga pattern, including message flows, failure handling, idempotency, timeouts, and exactly-once vs at-least-once delivery guarantees.

System DesignTechnical Trade-offsAPI & Integrations
Author's notes

Started with 2PC because it felt safe, but the interviewer kept pushing on the coordinator failure scenario and I fumbled it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by framing the problem: coordinating atomic updates across services with independent failure modes. Then compare 2PC, 3PC, and Saga on consistency, availability, and complexity, walking through message flows and failure scenarios for each. Conclude with practical guidance on delivery guarantees, idempotency, and timeouts, emphasizing trade-offs and real-world applicability.

Pro tip: Google values pragmatic trade-offs over theoretical purity: highlight that 2PC/3PC are rarely used in modern microservices due to blocking and coordinator fragility, while Sagas with idempotent operations and compensating actions are preferred for scalability. Mention that exactly-once delivery is impossible in distributed systems; achieve effectively-once via at-least-once delivery plus idempotent consumers.

1. Clarify requirements and constraints

Ask about consistency needs (strong vs eventual), latency tolerance, failure models, and whether services are internal or third-party. This scopes the protocol choice.

2. Explain 2PC and 3PC with message flows

Describe 2PC phases (prepare/commit) and 3PC (canCommit/preCommit/doCommit), including coordinator and participant roles. Walk through failure cases: participant crash, coordinator crash, network partitions, and how 3PC reduces blocking but adds complexity.

3. Detail the Saga pattern and compensation

Explain choreography vs orchestration, forward recovery vs backward recovery, and compensating transactions. Walk through a sample flow (e.g., order, payment, inventory) and failure handling when a step fails.

4. Address delivery guarantees, idempotency, and timeouts

Discuss at-least-once vs exactly-once (impossible), and how to achieve effectively-once with idempotent operations (idempotency keys, dedup tables). Explain timeout strategies, retries with backoff, and dead-letter queues.

5. Compare and recommend

Summarize trade-offs: 2PC/3PC for strong consistency but poor availability and scalability; Saga for high availability and scalability but eventual consistency. Recommend based on use case, and mention hybrid approaches or outbox pattern.

Key Points to Mention

  • 2PC blocking problem and coordinator single point of failure; 3PC reduces blocking but assumes bounded network delays and can still fail under partitions.
  • Saga pattern: choreography (events) vs orchestration (central coordinator); compensating transactions must be idempotent and commutative where possible.
  • Idempotency: use idempotency keys, deduplication tables, and ensure operations are idempotent to handle retries safely.
  • Delivery guarantees: at-least-once is achievable; exactly-once requires idempotent consumers and transactional outbox/inbox patterns.
  • Timeouts and failure detection: use timeouts with retries and exponential backoff; consider circuit breakers and dead-letter queues for poison messages.
  • Real-world trade-offs: Google-scale systems often favor eventual consistency and Sagas over 2PC due to availability and latency requirements.

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