I’ve spent the last few weeks wrestling with a common problem in modern software design: how do you make microservices talk to each other reliably without turning your system into a tangled mess of API calls? You know the scenario—one service goes down, and suddenly everything is waiting or breaking. This frustration is exactly why I turned to events. Today, I want to show you a practical way to build a system that’s responsive, resilient, and ready for production. Let’s build it together.

Think of an event-driven system as a well-organized kitchen. When a customer places an order (an event), the chef doesn’t shout at the waiter every two minutes for updates. The order ticket goes up on a rail. The chef cooks, and when it’s ready, they put the plate out. The waiter picks it up. Each person does their job when the right signal appears. This is the core idea: services communicate by producing and consuming events, not by calling each other directly.

Why does this matter for you? Systems built this way handle failure better and scale more easily. If the notification service is busy, new user sign-ups aren’t blocked—they just wait in line. So, how do we build one?

We’ll use a powerful trio: FastAPI for its clean, async-ready web framework; Apache Kafka as our robust event streaming platform; and Python’s AsyncIO to make everything efficient. We’re creating two services. The first, a User Service, will handle HTTP requests. The second, a Notification Service, will listen for events and send emails or messages.

Let’s start with the backbone: Apache Kafka. You can run it locally with Docker. Here’s a basic docker-compose.yml to get it running quickly.

# docker-compose.yml
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181

  kafka:
    image: confluentinc/cp-kafka:latest
    depends_on: [zookeeper]
    ports:
      - "9092:9092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092

With Kafka running, we need to define what our events look like. This is crucial. If services agree on a clear contract, they won’t misunderstand each other. We’ll use Pydantic models in a shared module.

# shared/schemas.py
from pydantic import BaseModel
from datetime import datetime
from enum import Enum

class EventType(str, Enum):
    USER_CREATED = "user.created"
    USER_UPDATED = "user.updated"

class UserEvent(BaseModel):
    event_type: EventType
    data: dict
    timestamp: datetime = datetime.utcnow()
    event_id: str

Now, for the User Service built with FastAPI. It has one main job: accept a POST request to create a user, then publish an event without making the client wait for all downstream actions.

# user_service/main.py
from fastapi import FastAPI, HTTPException
from contextlib import asynccontextmanager
from aiokafka import AIOKafkaProducer
import asyncio
import json

app = FastAPI()
producer = None

@asynccontextmanager
async def lifespan(app: FastAPI):
    global producer
    producer = AIOKafkaProducer(bootstrap_servers='localhost:9092')
    await producer.start()
    yield
    await producer.stop()

app.router.lifespan_context = lifespan

@app.post("/users/")
async def create_user(user_data: dict):
    # 1. Save user to your database here...
    new_user_id = 123

    # 2. Create an event
    event = {
        "event_type": "user.created",
        "data": {"user_id": new_user_id, "email": user_data["email"]},
        "event_id": "unique_id_123"
    }

    # 3. Send it to Kafka, non-blocking
    await producer.send_and_wait("user-events", json.dumps(event).encode())
    return {"id": new_user_id, "status": "created"}

See what happened? The API returns a response as soon as the user is saved locally and the event is sent to Kafka. It doesn’t wait for the notification to be sent. This is a game-changer for performance. But what good is an event if no one is listening?

This leads us to our Notification Service. It runs independently, constantly listening for new events on the user-events topic.

# notification_service/consumer.py
from aiokafka import AIOKafkaConsumer
import asyncio
import json
import smtplib  # Example for email

async def consume_events():
    consumer = AIOKafkaConsumer(
        'user-events',
        bootstrap_servers='localhost:9092',
        group_id="notification-group"
    )
    await consumer.start()
    try:
        async for msg in consumer:
            event = json.loads(msg.value.decode())
            if event["event_type"] == "user.created":
                print(f"Sending welcome email to {event['data']['email']}")
                # Here you would call your real email service
    finally:
        await consumer.stop()

asyncio.run(consume_events())

It’s simple. It listens, processes, and acts. If this service crashes and restarts, Kafka will help it pick up where it left off, avoiding lost messages. But is this production-ready? Not yet. We must handle failures.

What happens if the email service is down? We shouldn’t lose the event. A common pattern is to use a Dead Letter Queue (DLQ). If processing fails, we push the event to a different Kafka topic (dead-letter-queue) for later inspection and retry. This makes your system much more robust.

# Example error handling in the consumer
try:
    await send_welcome_email(event['data']['email'])
except Exception as e:
    # Send the failed event to a DLQ topic
    await dlq_producer.send("user-events-dlq", msg.value)
    print(f"Failed to process event {event['event_id']}: {e}")

You might wonder, how do you test all this? For unit tests, mock the Kafka producer. For integration tests, tools like testcontainers can spin up a real Kafka instance in a Docker container, letting you test the full flow. Monitoring is also key. FastAPI has built-in endpoints for health checks (/health), and you can expose metrics to see how many events you’re processing.

Combining FastAPI’s speed, Kafka’s durability, and AsyncIO’s efficiency creates a potent foundation. Your services become independent, your system can handle traffic spikes, and failures are contained. You start thinking in terms of events and flows, not just request and response.

This approach has changed how I design systems. It shifts the focus from “who calls whom” to “what happens when.” Have you considered what a single, slow API dependency is doing to your user experience? Could moving that work to the background with events be the answer?

I hope this walkthrough gives you a clear starting point. Building this way requires a shift in thinking, but the payoff in resilience and scalability is immense. Try setting up these two services and watch them communicate seamlessly. If you found this guide helpful, please share it with a colleague or leave a comment below with your thoughts. Let’s keep the conversation going.