Event-driven architecture in FastAPI - Step-by-Step Execution

Concept Flow - Event-driven architecture

Event Occurs

↓

Event Captured by Listener

↓

Listener Triggers Handler Function

↓

Handler Processes Event

↓

Optional: Emit New Event

↓

Cycle Continues or Ends

This flow shows how an event triggers a listener, which runs a handler to process the event, possibly emitting new events.

Execution Sample

FastAPI

from fastapi import FastAPI
app = FastAPI()

@app.on_event("startup")
async def startup_event():
    print("App is starting")

This FastAPI code listens for the 'startup' event and runs a function that prints a message when the app starts.

Execution Table

Step	Event	Listener Action	Handler Output	Next Action
1	App starts	startup_event listener triggered	Prints 'App is starting'	No further events
2	User sends request	Route handler triggered	Processes request and returns response	Wait for next request
3	App shuts down	shutdown_event listener triggered	Cleanup tasks run	App stops
4	No event	No listener triggered	No action	Idle state

💡 Execution stops when no new events occur or app shuts down.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
event	None	"startup"	"request"	"shutdown"	None
handler_output	None	"App is starting"	"Response sent"	"Cleanup done"	None

Key Moments - 3 Insights

Why doesn't the handler run until the event occurs?

Because in event-driven architecture, handlers wait passively for their specific event to happen before running, as shown in execution_table step 1 where the handler runs only after the 'startup' event.

Can one event trigger multiple handlers?

Yes, multiple listeners can listen to the same event and run their handlers independently, but this example shows a single listener per event for simplicity.

What happens if no event occurs?

No handlers run and the system stays idle, as shown in execution_table step 4 where no event means no action.

Visual Quiz - 3 Questions

Look at the execution table, what is the handler output at step 1?

A "Cleanup done"

B "Response sent"

C "App is starting"

D No output

💡 Hint

Check the 'Handler Output' column for step 1 in the execution_table.

At which step does the app process a user request?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look for the event 'User sends request' in the execution_table.

If the app never shuts down, which step will never occur?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Step 3 corresponds to the 'App shuts down' event in the execution_table.

Concept Snapshot

Event-driven architecture in FastAPI:
- Events trigger listeners automatically.
- Listeners run handler functions when events occur.
- Handlers process events and can emit new events.
- Common events: startup, shutdown, request handling.
- Handlers wait passively until their event happens.

Full Transcript

Event-driven architecture means your program waits for events like app startup or user requests. When an event happens, a listener notices it and runs a handler function to respond. For example, FastAPI can run a function when the app starts to print a message. Handlers only run when their event occurs, so the app stays idle otherwise. This lets your app react to things as they happen, making it flexible and efficient.