Data Flow

Request Flow’s Data-Shaped Sibling

Request flow traces one call; data flow traces the data itself — where each type originates, which component owns it, and every path it takes to become useful. Ownership questions that hide inside diagrams become explicit here.

The Three Data Movements

Every system moves data three ways:

 1. WRITES (operational truth)      2. READS (serving)         3. DERIVATION
    trip created → Postgres            history ← replica+cache    trips + ratings
    location ping → Redis              driver map ← memory        → analytics via CDC
                                       match view ← geo index     → search indexes
 
 ownership rule: exactly ONE writer per data type;
 everything else reads through contracts or subscribes to changes

RideShare Data Map

Data	Born in	Owner/writer	Readers	Copies/derivatives
Trip records	Match event	Trip service (Postgres)	History, billing, support	CDC → warehouse
Driver positions	Driver app pings	Location service (Redis, TTL)	Matcher, ETA estimator	none — ephemeral
Payments state	PSP callbacks	Payment service	Trip service (status only)	Ledger events
Ratings	Rider/driver post-trip	Rating service	Matcher (driver score)	aggregates

Reading the table horizontally reveals coupling: matcher depends on two owners’ outputs — its latency budget includes their freshness guarantees.

Sync vs Async Paths

Data movement splits by tolerance:

 SYNC (user waits):                ASYNC (eventually):
 - trip insert on match            - receipt generation
 - payment authorization           - rating aggregates
 - cache write-through of          - warehouse ETL / analytics
   must-be-fresh data              - search indexing
                                   - notifications
 
 rule: async anything the user won't notice within seconds;
 sync only what the response IS

Misclassifying is expensive both ways: async where users need answers breaks UX; sync where nobody waits wastes the request thread and couples uptime.

The Derivation Pipeline

Derived data deserves first-class diagram status because it carries staleness:

 Postgres ──CDC──► Kafka ──► warehouse        lag: minutes (fine for BI)
                        └──► search index     lag: seconds (fine for search)
                        
 question every derived copy answers explicitly:
 "how stale may this be, and what happens to a user who sees stale?"
 - history feed 2 min stale: nobody notices ✓
 - payment status 2 min stale: support tickets ✗ → read from owner

Consistency Consequences Fall Out

The data map predicts consistency needs without theorem-dumping:

• One writer per type → no multi-master conflicts to resolve.
• Cross-type joins (trip + payment) happen at read time or via events — never shared tables.
• Ephemeral types (positions) can’t be inconsistent with anything durable — they expire.

Interview Framing

After drawing components, strong candidates overlay arrows for data: “trips are written once by TripService; everyone else reads via API or CDC.” That sentence pattern — noun, owner, verb, consumers — repeated per data type demonstrates the systems thinking interviewers actually grade. The follow-up probe (“what if payment service is down?”) lands on prepared ground: trip creation proceeds; settlement queues.