When Uber's Microservices Needed to Talk
Uber has over 4,000 microservices. When a rider requests a trip, the Trips service needs to notify Pricing, Matching, ETA, Notifications, Analytics, and Fraud Detection. If the Trips service called each one directly, a slow Fraud service would delay the entire ride request. Instead, Uber publishes a 'trip.requested' event to Kafka. All six services consume it independently. If Fraud is slow, only fraud checks are delayed - the ride is not affected.
Point-to-Point: One Message, One Consumer
Point-to-Point (Work Queue):
Producer --> [ Queue ] --> Consumer A (processes message)
--> Consumer B (waits for next)
--> Consumer C (waits for next)
Each message is delivered to EXACTLY ONE consumer.
Consumers compete for messages (competing consumers pattern).
Example: Image thumbnail generation
- User uploads photo
- One message per photo goes into 'thumbnails' queue
- 10 worker processes compete to grab messages
- Each photo is processed by exactly one worker
Technologies: RabbitMQ, AWS SQS, Celery, BullMQPub/Sub: One Message, All Subscribers
Pub/Sub (Event Broadcast):
+--> Subscriber A (Shipping) --> processes
Publisher --> [Topic] --> Subscriber B (Billing) --> processes
+--> Subscriber C (Analytics) --> processes
Each message is delivered to ALL subscribers.
Adding new subscribers does NOT require changing the publisher.
Example: Order placed
- Order service publishes 'order.completed' to Kafka topic
- Shipping service: creates shipping label
- Billing service: charges credit card
- Analytics service: updates dashboards
- Email service: sends confirmation
- All process the SAME event independently
Technologies: Apache Kafka, AWS SNS, Google Pub/Sub, Redis StreamsKafka: Both Patterns in One System
Kafka Consumer Groups - best of both worlds:
Topic: 'orders' (3 partitions)
Consumer Group A (Shipping): Consumer Group B (Analytics):
Consumer A1 reads Partition 0 Consumer B1 reads Partition 0
Consumer A2 reads Partition 1 Consumer B2 reads Partition 1
Consumer A3 reads Partition 2 Consumer B3 reads Partition 2
Within a group: Point-to-Point (each partition read by ONE consumer)
Across groups: Pub/Sub (BOTH groups see ALL messages)
This is why Kafka dominates event-driven architectures:
- Scale consumers within a group (add more workers)
- Add new consumer groups without touching producers
- Messages are retained (replay old events for new services)Comparison Table
Feature Point-to-Point Pub/Sub
------------------- ------------------- -------------------
Consumers per msg Exactly 1 All subscribers
Use case Work distribution Event notification
Scaling pattern Add competing Add subscriber
consumers groups
Message after read Deleted from queue Retained (Kafka)
Ordering Per-queue FIFO Per-partition FIFO
Example Thumbnail gen, Order events,
email sending notifications
Technologies SQS, RabbitMQ Kafka, SNS, Pub/SubInterview Tip
When an interviewer asks about service communication, say: 'For synchronous request-response, I use HTTP/gRPC. For asynchronous events where multiple services need to react, I use Kafka with pub/sub - each service has its own consumer group. For task distribution like thumbnail generation, I use a point-to-point queue like SQS. The key distinction is: if only ONE service should process it, use a queue. If MULTIPLE services should react, use pub/sub.'
Key Takeaway
Point-to-point distributes work among competing consumers (each message processed once). Pub/Sub broadcasts events to all subscribers (each message processed by all). Kafka supports both via consumer groups. Most event-driven architectures use pub/sub for events and point-to-point for tasks.