To master real-time AWS applications, focus on events rather than handling a constant stream of requests.

Attending a full-day tech conference can be overwhelming with all the information you take in. On 01 November 2025, I got to attend the AWS Student Community Day in Tirupati. The event featured many great sessions about different parts of cloud computing.

The last session of the day really changed how I think about building modern applications. Poobalan gave a talk called "When Systems Listen: Event Driven Architecture." Even though it was late in the day, everyone was energized, and the ideas he shared were very practical.

I took lots of notes and snapped photos of the slides to capture everything. Now, I’ll share what I learned about Event-Driven Architecture (EDA) and explain why it’s important for developers today.

The "Are We There Yet?" Problem

Before we can see why Event-Driven Architecture matters, it helps to look at how traditional systems talk to each other. Poobalan kicked off the session with a familiar example: ordering food online.

Think about ordering your favorite meal on a food delivery app like Swiggy or Zomato. After you place your order, you watch your screen, waiting for updates. With traditional request-driven systems, your app would keep asking the restaurant's server, "Is it ready yet? How about now? Is it cooking now?"

Does this sound familiar? This is known as polling. Imagine being on a road trip with a child in the backseat who keeps asking if you are there yet. In software, this kind of constant checking uses up resources, puts extra strain on servers, and can cause annoying slowdowns. In the presentation, a funny meme showed a guy sitting alone on a park bench, which summed up the pain of always 'checking for updates.'

You might be wondering, isn't there a better way to handle this?

Enter Event-Driven Architecture

Here’s where things get interesting. Event-Driven Architecture changes the usual approach. Instead of components always checking in with each other for updates, the system follows the old Hollywood saying: "Don't call us, we'll call you."

In an EDA setup, components communicate by sending and receiving events. When something happens in your application, it sends out an event. Other services that are interested in that event listen for it and respond as needed.

The Anatomy of an Event

The slides explain that an event is just a change in your system’s state. There are also three main rules that define what makes something a true event:

Past tense: Events should describe something that has already happened. For example, use names like "Order Created" or "User Signed Up" instead of "Creating Order."
Immutable: After you publish an event, you will not be able to make any changes to it.
Decoupled: The system that publishes the event does not know who is consuming it, and it is not concerned with this information.

The Three Musketeers of EDA

The system that sends out the event does not know who will receive it, and it does not need this information.

Event Producers: These systems or services create events whenever something changes, such as when a customer clicks the checkout button on an online store.
Event Router/Broker: You can think of this part like a post office. It takes in events and sends them to where they need to go.
Event Consumers: These services wait for certain events so they can respond and do their jobs, such as sending a confirmation email after an order is placed.

Traditional vs. Modern: The Showdown

If you usually build request-driven applications, moving to event-driven architecture means thinking differently. In the session, a clear side-by-side comparison helped show exactly how the two approaches differ.

In a Request-Driven setup, communication happens in real time. The client sends a request and waits for a response. Since the systems are closely linked, if one service is slow, everything else slows down too. This setup does not scale well, and heavy traffic can quickly lead to bottlenecks across the system.

In EDA, communication happens asynchronously. When a client sends an event, it can continue working right away. The systems are loosely coupled, so responses do not block the process. This setup makes it possible to handle millions of independent events without slowing down the main application thread.

Here’s the main idea: request-driven systems are like calling someone and expecting them to answer right away. EDA is more like sending a letter; the person can read it and respond when it suits them.

Why We Should Care

Switching to an event-driven model brings several important benefits for today’s cloud applications:

Loose Coupling: Since services don’t need to know about each other, different teams can develop, deploy, and update them independently.
Real-Time Responsiveness: Systems can respond to changes the moment they happen, which allows for instant decision-making.
Resilience: If your email notification service goes down, your checkout service keeps working. It continues sending "Order Placed" events, which can be replayed when the email service is running again.
Cost-Effective: When you remove the need for constant polling, you can greatly lower your operational and computing costs.

Building EDA on AWS

At AWS Student Community Day, Poobalan moved on to talk about the main AWS services that support Event-Driven Architecture. These are the tools you use to build these systems.

Amazon EventBridge

This service is a serverless event bus that links your applications. It works like an event traffic controller by taking in events, checking them against rules you set, and sending them to the right places.

Amazon SNS (Simple Notification Service)

This service uses a publisher/subscriber model for messaging. Its main job is to broadcast messages. Picture it as 'one message, many listeners.' If you need to notify several backend services at once when an event happens, SNS is the right choice.

Amazon SQS (Simple Queue Service)

SQS is a message queue. It stores messages safely until the coSQS is a message queue that keeps messages safe until your services are ready to handle them. Imagine your database as a library, and 500 people try to check out a book at the same time. SQS works like a message waiting room, putting everyone in order so the librarian is not overwhelmed and no requests are missed.

Seeing it in Action: The Ride Booking App

Learning theory is helpful, but seeing it in action really helps it sink in. In the presentation, we watched a live demo with a made-up taxi ride-booking app.

We looked at the Amazon EventBridge console on the screen, which showed different routing rules. There was one rule named ride-to-driver-matching and another called driver-to-notification.

When someone clicked "Book a Ride" on the app, it triggered an event. We saw the Service Control Panel and the Ride Status Dashboard update right away. Thanks to event-driven architecture, the Driver Matching Service and the Notification Service worked on their own without depending on each other.

The dashboard displayed progress bars moving from "Ride Requested" to "Driver Assigned" and then to "Confirmation Sent." If the Notification Service went down for a bit, the app kept running. The driver was still assigned, and the notification just waited in a queue until the service was back online to handle it.

Is EDA the Silver Bullet?

EDA is impressive, but it is not the right solution for every project. The speaker made it clear when to use it and, just as importantly, when to avoid it.

When to use EDA: Event-driven design works best when you need real-time responses, high scalability, and flexibility through decoupling. It is ideal for complex systems with many producers and consumers, or when integrating different platforms.

When NOT to use EDA: Setting up event buses and queues can make your architecture more complex. If you are working on a simple CRUD application, a small prototype, or an app that needs strictly ordered and immediate responses, it is better to use traditional request-driven architectures. In some cases, a simpler approach is best.

Doing it Right: Best Practices

If you are ready to start using EDA, here are some important best practices to help keep your systems stable:

Idempotency: This idea sounds complex, but it is simple. Make sure your consumers can handle processing the same event more than once without causing errors or creating duplicate records.
Error Handling: Networks sometimes fail. Set up retries for temporary issues, and use Dead Letter Queues (DLQs) to store events that cannot be processed, so you can review them later.
Scalability: Set up your event channels with partitioning and load balancing. This way, your system can handle more traffic smoothly when demand increases.
Monitoring & Logging: Since events move through different systems at different times, debugging can be hard. Use observability tools to track and visualize event flows, so you always know what is happening in your system.

Key Takeaways

Here are the main ideas I’m bringing back to my own projects after this packed session:

Stop the polling: Switching from always checking on progress to a setup that just waits for notifications can save a lot of computing power.
Decoupling is a superpower: If your backend services don’t depend on each other, teams can build, scale, or even have issues without affecting the whole app.
AWS does the heavy lifting: Tools like EventBridge, SNS, and SQS work like a post office and waiting room, so it’s easy to route and store messages safely.
Complexity isn't always the answer: Even though I enjoyed the session, EDA isn’t always needed. Simple apps don’t need this much engineering, and that’s totally fine.

Conclusion

In short, going to the last session at AWS Student Community Day Tirupati was a great way to wrap up an already fantastic event. Poobalan managed to take a complex architectural idea and explain it using real-life examples.

Event-Driven Architecture helps our systems act more like the real world by reacting to events as they happen, instead of needing constant updates. It takes a new way of thinking, but the benefits in scalability, cost savings, and resilience make it worth learning.

About the Author

As an AWS Community Builder, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch! 🚀

🔗 Connect with me on LinkedIn