What's so hard about testing Event-Driven Architectures?

At its hard, event-driven architectures are quite simple. However, testing them can be quite a challenge because of their asynchronous nature and the fact that it's often difficult to find out what events have been published. These are only two of the challenges of testing event-driven architectures.

In this video, let's break down all the factors that make testing event-driven architectures on AWS such a daunting task.

✅ Recommended playlists:

Learn to build Production-Ready Serverless Applications

My BEST videos of 2023

🔔 For more free videos on YouTube, subscribe to my channel:

💌 If you're hungry for more insights, best practices, and tips on building serverless applications, make sure to subscribe to my weekly newsletter and elevate your serverless game!

📚 My courses 📚

👨‍🏫 My hands-on serverless workshop 👨‍🏫

🌐 Find me here

[theburningmonk]

You can get 15% OFF with the code "pandatube15" during checkout.

[maxmaximus]

@theburningmonk Why does everyone seem to concentrate on eventbridge for event driven architectures when sns can do the same thing, and not only happens to be cheaper but also faster (latency wise).

The subscribers just have to subscribe to the topic and use filters to only receive the data they need. A subscriber can also consume the data through an SQS queue attached to control the flow of data between itself and SNS.

I'm genuinely curious as to why everybody just seem to automatically default to eventbridge even if they are mainly using them for AWS services (as opposed to third party integrations where eventbridge shines).

Am I missing something here?