Design Tipping System - System Design | WinJob

Problem Statement: Post-Trip Tipping on Ride & Delivery Platforms

Drivers at Uber treat tips as latency-sensitive compensation signal; your design must credit wallets without blocking the rider rating flow.

Concern	Design stance
Truth source	Append-only `tip_ledger_event` — never adjust driver balance without an event
Fare basis	Percentage tips compute on locked `fare_subtotal_cents` at trip completion
Capture	Idempotent POST with Idempotency-Key; separate tip intent when refunds are common
Payout	Connect transfer after CAPTURED; instant payout optional with explicit fee

Section focus (sec-001): Uber and Lyft riders tip after trip completion; DoorDash and Instacart tip at order handoff. Money must never disappear between rider card capture and driver wallet credit.

Capacity signal: evening peak ~14k tip authorizations/s in primary region

javaOne Dark Pro

1 public record TipIntent(String tripId, int tipCents, String riderId, String state) {}
2 public final class TipLedgerEvent {
3   private final String eventType; // AUTHORIZE, CAPTURE, TRANSFER, REVERSE
4   private final long occurredAtEpochMs;
5 }

pythonOne Dark Pro

1 def compute_percent_tip(subtotal_cents: int, percent: int) -> int:
2     raw = subtotal_cents * percent // 100
3     return min(raw, subtotal_cents * 2)  # 200% cap

typescriptOne Dark Pro

1 export interface CreateTipRequest {
2   tripId: string;
3   tipCents: number;
4   idempotencyKey: string;
5   presetId?: "p15" | "p20" | "p25" | "custom";
6 }

Operational trace (sec-001)

Scenario 1: rider selects 20% preset on a $24.50 subtotal, API returns AUTHORIZED in 180ms, webhook confirms capture, payout worker enqueues transfer to driver Connect account. Finance reconciles PSP settlement batch IDs to tip.captured events keyed by trip_id.

On-call metrics: ledger_psp_mismatch_bps, tip_edit_after_transfer_count, instant_payout_failure_rate — sustained mismatch above 5 bps triggers SEV2.

Interview pivot (understanding): If challenged on cash tips, log driver-reported cash as non-authoritative analytics only. For combined fare+tip charge, show refund decomposition table before committing.

Why interviewers care

Tipping System interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Post-Trip Tipping on Ride & Delivery Platforms that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Ledger append-only invariant (sec-001)
•Fare snapshot before percent tip (1)
•Idempotent tip capture (understanding)
•Connect payout after CAPTURED (0)

1	public record TipIntent(String tripId, int tipCents, String riderId, String state) {}
2	public final class TipLedgerEvent {
3	private final String eventType; // AUTHORIZE, CAPTURE, TRANSFER, REVERSE
4	private final long occurredAtEpochMs;
5	}

1	def compute_percent_tip(subtotal_cents: int, percent: int) -> int:
2	raw = subtotal_cents * percent // 100
3	return min(raw, subtotal_cents * 2) # 200% cap

1	export interface CreateTipRequest {
2	tripId: string;
3	tipCents: number;
4	idempotencyKey: string;
5	presetId?: "p15" \| "p20" \| "p25" \| "custom";
6	}

Problem Statement: Post-Trip Tipping on Ride & Delivery Platforms

Operational trace (sec-001)

Why interviewers care

Interview checkpoint

Key Highlights

Section Rescue Kit