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

SeniorPrefer not to say

May 2026

Summary

System design round at Expedia for a software engineer role. The main problem was designing a synchronous order cancellation and refund processor, which sounds straightforward until you get into the weeds of distributed state and partial failures. Pretty intense for a single question but they clearly wanted depth.

Questions Asked (1)

Design a synchronous order cancellation and refund processor. The API must return a definitive success or failure only after the cancellation and refund are fully resolved, not fire-and-forget. Cover order state validation, payment gateway integration, atomic state updates across order/payment/inventory, partial failure handling, idempotency, distributed transactions vs compensation-based approaches, and timeout/circuit breaker patterns.

System DesignAPI & IntegrationsTechnical Trade-offs

Author's notes

This took up the entire session.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the synchronous requirement and the need for a definitive response, then walk through the end-to-end flow: validate order state, call payment gateway, update order/payment/inventory atomically, and handle partial failures with compensation. Emphasize idempotency, timeout/circuit breaker patterns, and the trade-offs between distributed transactions and compensation-based approaches.

Pro tip: Highlight that true atomicity across services is impractical; instead, use a saga pattern with compensating actions and ensure idempotency to handle retries safely. Also, mention that synchronous APIs should have a timeout budget and fallback strategies to avoid hanging clients.

1. Clarify Requirements and Constraints

Ask about expected load, consistency requirements, and whether partial failures can be tolerated. Confirm that the API must be synchronous and return a definitive result.

2. Design the High-Level Flow

Outline the sequence: validate order state, initiate refund with payment gateway, update order status, and release inventory. Ensure each step is idempotent and can be retried safely.

3. Address Atomicity and Partial Failures

Discuss why distributed transactions (e.g., 2PC) are often avoided and propose a compensation-based approach (saga) with compensating actions for each step. Explain how to handle failures at each stage.

4. Implement Idempotency and Timeouts

Use idempotency keys for the cancellation request and for calls to external services. Set timeouts on all network calls and use circuit breakers to prevent cascading failures.

5. Define Error Handling and Response

Specify how to return success or failure, including error codes and messages. For partial failures, decide whether to retry, compensate, or return a failure with details.

Key Points to Mention

Idempotency: Use idempotency keys to ensure repeated requests don't cause duplicate refunds or state changes.
Compensation-based approach (Saga pattern): Instead of distributed transactions, use a series of local transactions with compensating actions for rollback.
Order state validation: Check if the order is in a cancellable state (e.g., not shipped) and if it's already cancelled.
Payment gateway integration: Handle timeouts, retries, and idempotent refund requests; consider async refunds if the gateway doesn't support synchronous refunds.
Atomic state updates: Use database transactions for local updates (order, payment, inventory) and ensure consistency across services via sagas.
Timeout and circuit breaker patterns: Set aggressive timeouts and use circuit breakers to avoid blocking the client and to handle downstream failures gracefully.

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