Event-driven architecture: events, queues and serverless functions
In an event-driven design, parts of your system react to things that happen instead of calling each other directly. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, and what to decide first.
Quick answer
An event-driven architecture publishes something that happens, such as an upload or an order, as an event. An event bus routes it, a queue holds the work, serverless functions react and store results, and workflows coordinate multi-step jobs. The parts stay loosely coupled and scale on their own.
| Best for | Workloads with bursts or many independent steps, such as order processing, file handling and notifications |
|---|---|
| Less suited when | Simple apps where one request needs one immediate answer from one service |
| Start with | One event source, one queue and one function, with a dead-letter queue and alerts |
| Main services on AWS | Amazon API Gateway, AWS Step Functions, Amazon EventBridge, Amazon SQS, AWS Lambda, Amazon DynamoDB |
| Main services on Azure | Azure API Management, Azure Logic Apps, Azure Event Grid, Azure Service Bus, Azure Functions, Azure Cosmos DB |
| Main services on Google Cloud | API Gateway, Workflows, Eventarc, Pub/Sub, Cloud Run functions, Firestore |
The idea in plain words
In a request-and-response system, one service calls another and waits. In an event-driven system, something happens, an event is published, and any interested service reacts when it is ready. The sender does not know or wait for the receivers.
That makes the parts independent. A queue absorbs bursts so work is done at the pace you choose, serverless functions run only when there is work, and a failure in one part does not stop the others.
The price is that the system is harder to follow. Plan for duplicate events, out-of-order delivery, retries and tracing from the start.
The architecture
Boxes show the job each part does. Pick a cloud to see the service for each job.
Step by step
- Something happensA file is uploaded, an order is placed or a timer fires. The source creates an event that describes it.
- The event is publishedThe source sends the event to an event bus, without knowing who will use it.
- Rules route the eventThe bus matches the event against rules and sends it to the right targets, which can be queues, functions or other services.
- A queue holds the workA queue stores messages until a worker is ready, smoothing out bursts and keeping messages if a worker fails.
- Functions do the workServerless functions read messages, run your code and scale up or down with the amount of work.
- Results are storedFunctions write results to a data store and can publish new events for other parts to react to.
- Failures are handledFailed messages are retried and then moved to a dead-letter queue for review, and alerts tell you when it grows.
Services side by side
The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.
| Job | AWS | Azure | Google Cloud |
|---|---|---|---|
| Publish and secure APIs |
|
|
|
| Workflows and orchestration |
|
|
|
| Event routing between services (event-driven) |
|
|
|
| Message queue (decouple parts of an app) |
|
|
|
| Serverless functions |
|
|
|
| NoSQL document or key-value database |
|
|
|
| Publish/subscribe and fan-out notificationsOptional |
|
|
|
Common variations
- Many receivers need the same event. Use publish/subscribe topics so one event reaches every subscriber, each with its own queue.
- A job has many steps that can fail. Use a workflow service to run the steps in order, retry them and undo earlier steps when a later one fails.
- Messages must be processed in order. Use ordered queues or partitions, and accept lower throughput in exchange.
- Events come from outside your system. Receive webhooks through an API gateway that validates them and turns them into events.
Serverless functions or containers for the handlers?
Event handlers can be small functions that run per event, or containers that run longer or need more control. Serverless containers are shown in the table.
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Run containers without managing servers |
|
|
|
Serverless functions
Good
- Start in milliseconds and cost nothing when idle
- Native triggers for queues, events and schedules
- Least to operate
Watch out
- Limits on run time, memory and package size
- Cold starts after idle periods
- Many small pieces to manage
Serverless containers
Good
- Any language or library
- Longer runs and more memory
- The same container works elsewhere
Watch out
- Slightly more to configure
- Fewer built-in event triggers
- Cost while kept running
Keep in mind
- Duplicates and idempotency. Messages can be delivered more than once. Make handlers safe to repeat, for example by recording which message IDs you have already processed.
- Ordering. Do not assume events arrive in order unless the service guarantees it. Design for out-of-order arrival.
- Failures and dead-letter queues. Set retry limits, send failed messages to a dead-letter queue and alert when it grows. Replay messages after you fix the bug.
- Tracing. Pass a correlation ID through every event, so you can follow one business action across services and logs.
- Cost and limits. Watch concurrency limits and the number of events. A bug that loops can create a very large bill, so set budget alerts and limits.
- Event design. Keep events small, named for what happened and versioned, and keep secrets and large files out of them.
- Testing. Test with real event samples and failure cases, and keep a way to replay events in a test environment.
Words used on this page
Services in this pattern that have changed
Cloud providers rename and retire services often. These affect the parts above. Checked on 23 October 2026.
- AWS Closed to new customers AWS App Runner stopped accepting new customers on 30 April 2026. AWS recommends Amazon ECS Express Mode for new container web apps. Details
- Azure Renamed Azure Cosmos DB for MongoDB (vCore) is now Azure DocumentDB. Details
- Google Cloud Renamed Dataproc is now Managed Service for Apache Spark, and Cloud Composer is now Managed Service for Apache Airflow. Details
- Google Cloud Renamed Cloud Functions is now Cloud Run functions. Details
Sources and further reading
Check details such as features, limits, prices and regions in the providers' own documentation.
- AWS documentation (opens in a new tab)
- Microsoft Azure documentation (opens in a new tab)
- Google Cloud documentation (opens in a new tab)
Announcements about the changed services above
Frequently asked questions
What is event-driven architecture?
It is a way of building a system so that one part announces what happened (an order was placed, a file arrived) and other parts pick that up and act on it, rather than being called one by one. Parts stay loosely coupled, and each can scale on its own.
What is the difference between an event bus and a message queue?
An event bus routes events to many possible listeners using rules, while a queue holds messages for workers that process each one. They are often used together: the bus routes and queues buffer.
Is serverless the same as event-driven?
No. Serverless means you do not manage servers, while event-driven describes how parts communicate. They fit well together, because serverless functions react to events and scale with them.
When should I not use event-driven design?
Avoid it for simple apps where one request needs one immediate answer from one service. The extra moving parts, retries and tracing are not worth it there.
How do I debug an event-driven system?
Use correlation IDs across events and logs, keep dead-letter queues for failed messages, and use tracing tools to follow one action through the services.
Want this reviewed for your case?
CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.
Building something else?
Describe it in plain words and get matching services on all three clouds.
Service suggester → Cloud consulting →