Problem Statement: Trip-Scoped Driver-Rider Chat
Problem Statement: Trip-Scoped Driver-Rider Chat — driver-rider chat interview depth
Problem Statement: Trip-Scoped Driver-Rider Chat
Section 1 — Uber and Lyft open a chat channel the moment a trip is matched so parties can coordinate pickup pins, gate codes, and wheelchair access without exchanging personal phone numbers. The product is not a social network: every message is bound to trip_id, expires after trip completion, and must survive flaky mobile networks in parking garages.
| Signal | Target |
|---|---|
| deliver_p99 | 200ms |
| push_fallback_p99 | 3s |
| masked_call_setup | 2s |
| moderation_queue_lag | 30s |
Architecture note for Problem Statement: Trip-Scoped Driver-Rider Chat: the Chat Platform treats trip_id as the sole partition key so every message inherits trip lifecycle policies. Clients never see raw phone numbers—only MaskedSession handles PSTN bridging, while the authoritative transcript lives in Postgres with client_msg_id deduplication.
Operational depth: when Trip FSM emits TRIP_COMPLETED, Chat Service transitions thread to FROZEN then CLOSED, revokes relay numbers, and stops WS fanout within 500ms. Support elongation requires support_case_id—consumer APIs return 410 THREAD_CLOSED otherwise.
Interview pivot: contrast this design with generic messaging (Slack/WhatsApp). Here, graph size is two participants, ordering is total per thread, and retention is compliance-driven—not user-controlled inbox search.
1 public record Msg001(String tripId, String clientMsgId, long serverSeq) {}
1 def chat_001_budget_ms() -> int: 2 return 200 # deliver_p99 budget
1 export interface Chat001Envelope { tripId: string; threadId: string; serverSeq: number; }
Why interviewers care
Driver-Rider Chat interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.
Interview checkpoint
Name one failure story for Problem Statement: Trip-Scoped Driver-Rider Chat that proves you understand real outages, not happy-path diagrams.
Key Highlights
- •Problem Statement: Trip-Scoped Driver-Rider Chat: trip_id partition + server_seq ordering
- •Masked relay expires on trip end — never reuse numbers
- •Idempotent POST /messages with client_msg_id
- •deliver_p99 ≤ 200ms online; push fallback ≤ 3s
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Trip-Scoped Driver-Rider Chat, I'll anchor on trip_id partitioning before naming cloud SKUs."
- "If relay fails, I degrade to in-app text—never leak personal numbers."