Practice/Uber/Design a Payment System for Ride-Sharing

Design a Payment System for Ride-Sharing

System DesignOptional

Problem Statement

Design a payment system for a ride-sharing service like Uber that handles payment processing for rides, including fare calculation, payment authorization, driver payouts, and refund handling. The system must process millions of payment transactions daily with high reliability, supporting multiple payment methods and currencies.

The core challenge is building a financial system that guarantees exactly-once payment processing, handles partial failures gracefully (e.g., ride completed but payment fails), supports complex fare structures (surge pricing, promotions, tips), and produces accurate financial records for reconciliation. Unlike e-commerce payments where the amount is known upfront, ride-sharing payments require post-trip fare calculation with potential adjustments.

Interviewers at Uber ask this to test whether you can design a financially correct system with idempotent transactions, saga-based workflows for multi-step payment flows, ledger-based accounting, and graceful degradation when payment providers are unavailable.

Key Requirements

Functional

• Fare calculation -- compute the ride fare based on distance, duration, surge multiplier, promotions, and tips after trip completion
• Payment processing -- authorize and capture payments from riders using credit cards, digital wallets, or other payment methods
• Driver payouts -- calculate driver earnings (fare minus commission) and batch payouts on a weekly schedule
• Refunds and adjustments -- process full or partial refunds for disputed charges, with audit trails for every financial operation

Non-Functional

• Scalability -- handle millions of payment transactions per day with peak throughput during commute hours
• Reliability -- zero financial inconsistency; every charge has a corresponding ledger entry; 99.99% payment success rate
• Latency -- fare calculation within 1 second of trip completion; payment authorization within 3 seconds
• Consistency -- strong consistency for all financial operations; exactly-once payment semantics

What Interviewers Focus On

Based on real interview experiences at Uber, these are the areas interviewers probe most deeply:

1. Idempotent Payment Processing

Payment operations must be exactly-once despite network retries and worker crashes. Charging a rider twice is unacceptable.

Hints to consider:

• Assign a unique payment_id (idempotency key) to each trip's payment at fare calculation time
• Use this key in all payment provider API calls so retries are automatically deduplicated by the provider
• Store payment state transitions (calculated, authorized, captured, failed) in a state machine with conditional updates
• Check the current state before each operation: if already captured, return success without re-charging

2. Multi-Step Payment Workflow (Saga Pattern)

A ride payment involves multiple steps: fare calculation, payment authorization, ledger posting, and driver earning credit. Each step can fail independently.

Hints to consider:

• Model the payment flow as a saga with compensating actions: if capture fails, release the authorization hold
• Use a durable workflow engine or state machine to track progress through each step
• Design each step to be individually idempotent and retriable
• Handle edge cases: rider's card declined after trip completion (deferred collection), insufficient funds (retry schedule)

3. Ledger Design and Financial Accuracy

Every dollar movement must be traceable in an immutable ledger. Interviewers expect double-entry accounting principles.

Hints to consider:

• Record every financial event as a pair of ledger entries: debit from rider, credit to the platform; debit from platform, credit to driver
• Make ledger entries immutable and append-only; corrections are new reversal entries, not mutations
• Maintain running balances as materialized views computed from ledger entries
• Support reconciliation: periodically verify that internal ledger balances match payment provider settlement reports

4. Driver Payout Batching

Driver payouts happen on a schedule (weekly) and aggregate many individual trip earnings. Interviewers look for efficient batch processing with correctness guarantees.

Hints to consider:

• Accumulate driver earnings from completed trip ledger entries throughout the week
• At payout time, compute net earnings (gross fares minus commission, minus adjustments) per driver
• Submit payout batches to the banking system with idempotency keys per payout period per driver
• Handle payout failures with automatic retry and manual escalation for persistent issues