Design Fare Splitting - System Design | WinJob

Problem Statement: Multi-Rider Fare Splitting

Fare splitting (Uber Split Fare, Lyft shared pay, Grab group trips) is a post-trip settlement problem: one organizer divides an immutable trip_fare_snapshot across verified co-riders, then the platform orchestrates parallel card captures without breaching sum-to-total invariants.

Concern	Design stance
Truth source	Append-only `split_ledger_event` — never mutate balances silently
Snapshot	Lock totals at trip completion; invites reference locked cents
Orchestration	Saga with timeouts; organizer backstop on hard declines
Compliance	Tokenized instruments via PSP; platform stores payment_method_id only

Section focus (sec-001): Uber Split Fare and Lyft shared-payment flows let one organizer divide a completed trip total across verified co-riders before cards are captured. The platform must freeze a fare snapshot, invite participants, collect partial authorizations, and close the split only when obligations sum to the trip total.

Capacity signal: 8M weekly split attempts; evening peak 12k split-settle RPS

javaOne Dark Pro

1 public record SplitShare(String userId, int shareCents, String state) {}
2 public final class FareSplitSnapshot {
3   private final String tripId;
4   private final int totalCents;
5   private final long lockedAtEpochMs;
6 }

pythonOne Dark Pro

1 def allocate_equal(total_cents: int, riders: int) -> list[int]:
2     base, rem = divmod(total_cents, riders)
3     shares = [base] * riders
4     for i in range(rem):
5         shares[i] += 1
6     assert sum(shares) == total_cents
7     return shares

typescriptOne Dark Pro

1 export interface SettleSplitRequest {
2   splitId: string;
3   idempotencyKey: string;
4   organizerBackstop: boolean;
5 }

Operational trace (sec-001)

Walkthrough: organizer taps Split, invites three contacts, each accepts within 15 minutes, fare snapshot locks at trip end, settlement saga captures four cards. Finance reconciliation compares PSP settlement batches to split.settled events keyed by trip_id.

On-call metrics: duplicate_capture_rate, stuck_saga_count, organizer_backstop_cents — sustained duplicate capture above 0.005% is revenue-critical.

Interview pivot: If asked about in-ride splitting, defer to phase-2; MVP settles only after trip.completed to avoid reroute disputes. For Grab multi-stop, mention optional distance-weighted shares behind the same ledger interface.

Why interviewers care

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

Interview checkpoint

Name one failure story for Problem Statement: Multi-Rider Fare Splitting that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Snapshot lock at trip complete (sec-001)
•Ledger idempotency on capture (1)
•Organizer backstop policy explicit (understanding)
•PSP webhook dedupe before state advance (0)

1	public record SplitShare(String userId, int shareCents, String state) {}
2	public final class FareSplitSnapshot {
3	private final String tripId;
4	private final int totalCents;
5	private final long lockedAtEpochMs;
6	}

1	def allocate_equal(total_cents: int, riders: int) -> list[int]:
2	base, rem = divmod(total_cents, riders)
3	shares = [base] * riders
4	for i in range(rem):
5	shares[i] += 1
6	assert sum(shares) == total_cents
7	return shares

1	export interface SettleSplitRequest {
2	splitId: string;
3	idempotencyKey: string;
4	organizerBackstop: boolean;
5	}

Problem Statement: Multi-Rider Fare Splitting

Operational trace (sec-001)

Why interviewers care

Interview checkpoint

Key Highlights

Section Rescue Kit