Have you ever watched a kitchen during a busy dinner service? One chef shouts “Two burgers!” and instantly, others start moving—the grill cook fires up patties, the fry cook drops fries, the expeditor grabs plates. No one is making direct requests; they’re responding to events. This is how modern software systems need to work. I kept hitting a wall with my own projects: my services were too chatty, too fragile. A single slow-down would cause a cascade of failures. That frustration led me to a better pattern. Let’s build systems that work like that kitchen—responsive, resilient, and independent.
Traditional methods often rely on services calling each other directly, like a phone call. It’s synchronous and demanding. Event-driven design is different. Services communicate by broadcasting messages about things that have happened. Other services listen and react only if they care. This creates a system that is loosely coupled. One service doesn’t need to know the details of another, just the structure of the event. This approach scales well and handles failures gracefully.
Why use FastAPI, RabbitMQ, and Pydantic together? They form a strong, modern toolkit. FastAPI gives us a fast, clean way to build web endpoints with automatic documentation. RabbitMQ is a mature and reliable message broker that routes our events. Pydantic ensures our data is valid and structured correctly at every step. Using Python’s async features with aio-pika makes our message handling non-blocking and efficient.
Let’s picture a simple online store. A customer places an order. This single action should trigger several tasks: reserve stock, charge a payment, and send a confirmation email. In a brittle system, all these steps happen in a single, long chain. If the inventory service is slow, the customer waits, and the payment might time out. How can we avoid this domino effect?
We design our system around events. The “order placed” action becomes an event—a packet of immutable facts. It states: “At this time, customer X ordered items Y and Z.” It doesn’t request anything; it simply announces. Our services are set up to listen. The inventory service hears this event and tries to reserve the items. The payment service hears it and processes the charge. The notification service hears it and prepares an email. They work in parallel, not in sequence.
We start by defining our events clearly. This is where Pydantic is invaluable. It lets us create strict blueprints for our data.
from pydantic import BaseModel, Field
from uuid import UUID, uuid4
from datetime import datetime
from enum import Enum
class EventType(str, Enum):
ORDER_CREATED = "order.created"
class OrderCreatedEvent(BaseModel):
event_id: UUID = Field(default_factory=uuid4)
event_type: EventType = EventType.ORDER_CREATED
timestamp: datetime = Field(default_factory=datetime.utcnow)
order_id: UUID
customer_email: str
items: list[dict]
# Example event instance
event_data = OrderCreatedEvent(
order_id=uuid4(),
customer_email="customer@example.com",
items=[{"product_id": "123", "quantity": 2}]
)
print(event_data.json())This code defines what an OrderCreatedEvent must contain. Pydantic checks the types: order_id must be a UUID, email a string. If we try to pass invalid data, it raises an error immediately. This validation is the first line of defense. When all services agree on these shapes, communication becomes reliable. Can you see how this prevents one malformed message from breaking the entire flow?
Next, we need a post office for our events: RabbitMQ. Our FastAPI service will publish events to it, not to other services directly.
# In a file like `publisher.py`
import aio_pika
import json
from our_events import OrderCreatedEvent
async def publish_order_created(event: OrderCreatedEvent):
connection = await aio_pika.connect_robust("amqp://localhost/")
async with connection:
channel = await connection.channel()
exchange = await channel.declare_exchange("orders", aio_pika.ExchangeType.TOPIC)
message_body = json.dumps(event.dict()).encode()
message = aio_pika.Message(message_body)
await exchange.publish(message, routing_key="order.created")Our FastAPI endpoint becomes very simple. Its job is to validate the incoming request, create the event, and publish it. It doesn’t wait for anything else to complete.
from fastapi import FastAPI, HTTPException
from publisher import publish_order_created
from our_events import OrderCreatedEvent
app = FastAPI()
@app.post("/order")
async def create_order(order_details: dict):
# ... validate order_details ...
new_event = OrderCreatedEvent(
order_id=uuid4(),
customer_email=order_details["email"],
items=order_details["items"]
)
await publish_order_created(new_event)
return {"status": "Order received", "order_id": new_event.order_id}The endpoint responds quickly, telling the user “Order received.” The actual work happens elsewhere, asynchronously. But what happens on the other side? Who is listening?
We build separate services, consumers, that subscribe to these events. Here is a simplified inventory service consumer.
# inventory_service/consumer.py
import aio_pika
import json
from our_events import OrderCreatedEvent
async def process_inventory():
connection = await aio_pika.connect_robust("amqp://localhost/")
async with connection:
channel = await connection.channel()
await channel.set_qos(prefetch_count=10)
exchange = await channel.declare_exchange("orders", aio_pika.ExchangeType.TOPIC)
queue = await channel.declare_queue("inventory_queue", durable=True)
await queue.bind(exchange, routing_key="order.created")
async for message in queue:
async with message.process():
body = json.loads(message.body.decode())
# Validate the incoming data against our Pydantic model
order_event = OrderCreatedEvent(**body)
print(f"Reserving stock for order: {order_event.order_id}")
# ... logic to update database ...This service runs independently. It connects to RabbitMQ, declares its interest in order.created events, and waits. When a message arrives, it processes it. If the inventory service crashes and restarts, RabbitMQ still holds the messages. The system is durable.
You might wonder, what if processing fails? Perhaps an item is out of stock. We handle this by publishing a new event, like inventory.reservation_failed. Another service could listen for that and notify the customer or suggest alternatives. Error handling becomes a matter of workflow, not a broken chain.
This pattern changes how we think about data flow. Services own their logic and data. The order service doesn’t need to know how inventory is managed. It just announces changes. This independence makes teams move faster and systems easier to change. Adding a new service, like one that updates a recommendation engine based on purchases, is simple. Just subscribe to the order.created event. No changes needed to the existing order flow.
Building systems this way requires a shift in mindset. We move from designing “request-response chains” to modeling “business process flows.” What are the important state changes in your domain? Those are your events. Who needs to know about them? Those are your services. Start small, model one core workflow, and see how the decoupling gives you new flexibility.
I hope this practical view helps you tackle that feeling of interconnected complexity. It did for me. If this approach to building software resonates with you, or if you have your own experiences with event-driven design, I’d love to hear about it. Share your thoughts in the comments, and if you found this guide useful, please pass it along to others who might be facing similar architectural puzzles. Let’s keep the conversation going.
As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!
101 Books
101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.
Check out our book Golang Clean Code available on Amazon.
Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!
📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!
Our Creations
Be sure to check out our creations:
Investor Central | Investor Central Spanish | Investor Central German | Smart Living | Epochs & Echoes | Puzzling Mysteries | Hindutva | Elite Dev | JS Schools
We are on Medium
Tech Koala Insights | Epochs & Echoes World | Investor Central Medium | Puzzling Mysteries Medium | Science & Epochs Medium | Modern Hindutva
