Stop 08 · Serverless & Event-Driven ArchitectureTopics · 4/9

Event-Driven Architecture Basics

In short

In most first projects, service A calls service B and waits. In event-driven systems, A just announces "this happened" and moves on. Whoever cares reacts in their own time.

Designing systems where components communicate by producing and reacting to events, rather than calling each other directly — improving decoupling and scalability, at the cost of some added complexity in tracing a full flow.

The blob character rings a hand bell as children run out and a canteen man opens his shutter.

Think of it like this

The school bell

When the lunch bell rings, the peon doesn't call each class and the canteen one by one. He rings once. Kids head out, the canteen uncle opens his shutter, teachers go to the staff room. One signal, many independent reactions.

Watch it happen

A photo upload, told as events

User app

S3 bucket

Thumbnail fn

Photos DB

PUT raw/cat.jpg

1/5The app uploads a photo and is done. It doesn't wait for any processing.

The big ideas

What you need to know

Events are facts

An event says what already happened, in past tense: OrderPlaced, FileUploaded. It isn't a command.

Loose coupling

Producers don't know their consumers. Add a new consumer without touching the producer's code.

Eventually consistent

Consumers finish a little later. Your UI must handle "processing" states gracefully.

Expect duplicates

Most event systems deliver at least once. Make consumers idempotent: handling twice gives the same result.

See it in code

Walk through the code

python

1import urllib.parse2 3def handler(event, context):4    for record in event["Records"]:5        bucket = record["s3"]["bucket"]["name"]6        key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])7 8        if key.startswith("thumbs/"):9            continue  # don't react to our own output10 11        print(f"New upload: s3://{bucket}/{key}")12        # make_thumbnail(bucket, key)

1/3The handler gets a batch of records and handles each one.

One S3 event can hold several records, so always loop. Object keys arrive URL-encoded, hence unquote_plus.

Save yourself the pain

Common mistakes

Oops

Triggering a function on a bucket and writing its output back to the same prefix.

Do this instead

Write output to another prefix or bucket and filter the trigger, or you'll create an infinite, costly loop.

Oops

Assuming each event arrives exactly once and in order.

Do this instead

Design for duplicates and reordering. Use IDs to skip work that's already done.

Your mission

Your first event chain

~40 min

Quick check

Your consumer might receive the same OrderPlaced event twice. What's the safest design?

Go deeper

1Diagram a hypothetical event-driven flow: an event produced by one service, consumed by another.
2Learn why event-driven architecture decouples services, letting them scale and fail independently.
3Understand the added debugging complexity: tracing a request across asynchronous event boundaries.