A common challenge in event-driven architectures is the potential for unintentionally triggering downstream consumers when running end-to-end tests.
Ephemeral environments can help, but not when you must publish events to a shared event bus.
In such cases, you can conditionally create a local copy of the event bus as part of the ephemeral environment so your test events will not trigger downstream event consumers.
Building Evolua, an AI-powered code reviewer, taught us a lot about balancing cost, performance, and developer experience.
While selecting the right LLM and crafting prompts is important, the real challenge lies in handling large PRs, mitigating model limitations, and ensuring a smooth user experience.
In this post, we break down our architecture, why we chose Bedrock, and key lessons learned – like why the LLM is actually the easy part. If you’re using AI to write code, Evolua can help catch bad code before it reaches production.
“High cohesion, low coupling” is one of the most cited, and yet, most misunderstood principles in software engineering.
So in this short post, let’s explain their difference with a few easy-to-understand examples.
There is more than one way to test user journeys that span multiple bounded contexts. Your choice depends on organizational structure, team responsibilities, and the maturity of your testing practices.
Ultimately, every part of the user journey should be tested, whether it’s done piecemeal by individual teams or centrally by a QA/cross-functional team.
In this article, let’s look at several ways you can approach this problem, depending on if you have full-stack teams or specialised frontend and backend teams. We will look at trade-offs and whether it’s best to host other teams’ services in your environment, or use mock APIs, or delegate testing user journeys to a QA team and use a dedicated integration environment for testing.
The ability to invalidate a user’s session with immediate effect is a common enterprise requirement.
However, this goes against how token-based authentication is designed to work. JWT tokens are stateless and are typically short-lived (for security reasons) but can be refreshed with refresh tokens.
So, is it possible to invalidate Cognito-issued JWT tokens?
The short answer is no.
The long answer is yes, you can achieve this effect with some work and some performance overhead.
How? Well, come in and find out!
So that’s it for this year’s re:Invent. Werner delivered his usual insightful keynote and shared some key lessons in dealing with complexity and warning signs to look out for. As Werner said, the number of moving parts is not a good measure of complexity on its own. And that’s something so many people get wrong …
DynamoDB cuts on-demand price by 50% Announcement DynamoDB has reduced on-demand pricing by 50% and global tables by up to 67%. Amazing! Lambda SnapStart is now available for Python and .Net Announcement Previously, SnapStart was only available for Java. It makes sense to add support for .Net. But why Python and not Node.js? I guess …
Biggest pre:Invent 2024 serverless announcements Read More »
One of the most misunderstood aspects of Lambda is how throttling applies to async invocations. Or rather, how it doesn’t!
The TL;DR is that you will never experience throttling when you invoke a function asynchronously.
It also means that despite SNS and EventBridge having longer retry periods than Lambda’s internal queue, these have no practical impact in the case of Lambda throttling.
Read the full post to understand why.
One under-appreciated aspect of designing an Event-Driven Architecture (EDA) is how much information you should include in your events.
Do you send light events or rich events?
Or perhaps you would send both, but in different circumstances?
In this post, let’s talk about the pros & cons of each and how they fit into my mental model of DDD and EDA.
This article is about best practices for building event-driven architectures on AWS, with a focus on wrapping events in custom envelopes when using EventBridge.
While EventBridge provides metadata by default, a custom envelope allows for a standardized, consistent structure across all of your events, making it easier to manage and evolve the system over time.
By providing your own metadata, you can gain better interoperability between different services, end-to-end observability, idempotency control and versioning.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.