Topic 16.4
Ride-Hailing Trip Events and an Activity Feed
In one line
For ride-hailing, Kafka carries trip lifecycle events (keyed by trip), driver location streams (keyed by driver, short retention) and analytics, while geo matching lives in an in-memory geo index. For activity feeds, Kafka carries post, comment, like and connection events into fan-out and ranking processors that build per-user feed read models.
Think of it like this
A taxi company's radio room. Location pings are constant chatter (short-lived), trip bookings are important records (kept and ordered), and the billing office and analysts read the same records later.
Key ideas
- 01
Ride-hailing topics:
driver.locations(key driverId, very high volume, retention hours, feeding the geo index in Redis or a geo service),trips.events(key tripId: Requested, Matched, PickedUp, Completed, Cancelled; long retention),payments.events, and analytics topics. - 02
Ordering: per trip via tripId keys; per driver location via driverId (a stale location arriving after a newer one must be ignored, using timestamps).
- 03
Hot keys: a busy airport region isn't a key problem if keys are driver or trip IDs; avoid keying by region for high-volume streams.
- 04
Activity feed (LinkedIn-style): events
PostCreated,CommentCreated,LikeCreated,ConnectionCreatedkeyed by actor or object. A fan-out processor writes feed entries for followers (push) except for high-follower accounts (pull at read time); a ranking service scores entries; the feed read model lives in a key-value store or Redis. - 05
Stream processing for feeds: aggregations ("12 people liked your post"), dedup of repeated actions, and notification triggers, each as consumer groups on the same events.
Code & diagrams
Interview problem
The problem
Design Uber's event backbone
Design the Kafka parts of a ride-hailing platform: driver location, ride requests, matching, trip events, notifications and payments. Discuss partition keys, ordering, the geo system, hot keys and consumer lag.
Explain it without notes
Why isn't matching done by consuming Kafka?
Practice
Sketch the LinkedIn activity-feed pipeline: topics, keys, consumer groups and read model.
Trade-offs
- ↔
Short-retention, high-volume streams and long-retention business events belong in separate topics with different settings.
Done when you can
I can design Kafka backbones for location-heavy and feed-style systems.