Event Driven Architecture 101
Guide to Async Programming

The Old Synchronous Way

Let's look at a real-world analogy: ordering food at a restaurant.

Suppose you're a waiter, and this is how you operate:

1. You take an order from Table 1
2. You go to the kitchen and wait until it's fully cooked
3. You serve it
4. Only then do you go to Table 2 to repeat the same steps
5. Then move to Table 3, and so on

This is exactly what synchronous code does — it waits at each step.

The Better Asynchronous Way

Now let's imagine a more efficient restaurant flow:

1. You take an order from Table 1 and pass it to the kitchen
2. While it's being cooked, you immediately take an order from Table 2
3. Then Table 3, and so on
4. As soon as a dish is ready, you serve it — regardless of table order

Let's See in Context of Programming: How Async Helps in Real Code

Suppose you're building a notification service that sends a confirmation email to each user after they sign up. Now imagine 100 users sign up at the same time.

function sendEmails(users) {
  for (let user of users) {
    sendEmail(user.email); // Wait until this email is sent
  }
}

async function sendEmails(users) {
  const promises = users.map((user) => sendEmailAsync(user.email));
  await Promise.all(promises);
}

Async in Real Life: Beyond Promises

So far, we've seen how async/await and Promise.all() help us run tasks in parallel in code. That works perfectly for small-scale tasks, like sending a few emails or loading UI data in a browser.

But what about real-world systems with:

• Thousands of users
• Millions of events
• Long-running operations
• The need for retries, persistence, and monitoring

At scale, promises alone aren't enough to handle real-world async processing needs. Instead, we use infrastructure-level patterns to handle this complexity — patterns built to decouple, scale, and reliably process massive volumes of async tasks.

Let's see some common patterns used in real-world backend systems:

1. Message Queues

Message queues are like buffers or queue that sit between two parts of your system — a producer (which creates tasks) and a consumer/worker (which performs those tasks).

They act as a connection point for multiple services. One service produces tasks in the queue and other services consume them at their own pace.

2. Message Streams

Message Streams are used when data keeps flowing — not just one-time tasks, but continuous updates.

Unlike message queues (1 producer → 1 consumer per message), message streams allow multiple producer → multiple consumer groups, where each group receives all messages independently. They're perfect when many services need to react to the same stream of events — like location updates, order events, or sensor data. Examples: Kafka, Kinesis.

Example: Uber Driver Location Streaming

In a service like Uber, every driver's app sends live GPS coordinates every few seconds.

{
  "driverId": "DR123",
  "lat": 28.6139,
  "lng": 77.209,
  "timestamp": 1690917600
}

These updates are pushed to a Kafka topic called driver-location-stream.

Service	What It Does
Nearby Driver Service	Shows drivers near a passenger
ETA Service	Continuously updates arrival times
Analytics	Tracks hotspots and trends
Fraud Detection	Detects fake GPS or route anomalies

Each service has its own consumer group. All groups receive every message independently, allowing their logic to stay isolated and process asynchronously. Within each group, messages are distributed among consumers for parallel processing.

How Kafka Distributes Work:

If a topic has 3 partitions (P0, P1, P2) and a consumer group has 3 consumers, each consumer gets one partition. If there are fewer consumers than partitions, some consumers handle multiple partitions. This ensures parallel processing while maintaining message order within each partition.

3. Pub/Sub (Publish-Subscribe)

In our journey through asynchronous processing, we've seen howmessage queues offer reliable task delegation and how message streams help process flowing data across consumers. But when it comes to real-time event delivery — think of notifications, live updates, or collaborative apps — the Publish-Subscribe (Pub/Sub) model shines.

Wrap Up

All the techniques we saw — message queues, streams, and pub-sub — are not just for performance optimization. They're the core of event-driven architecture, which helps in building scalable and loosely coupled systems.

These concepts are used in real-world apps like Uber, Netflix, and Facebook to handle massive flows of data in real time.

Stay Tuned!