What if you don’t have to worry about event versioning or catching breaking changes anymore?
What if event consumers are no longer coupled to the schema of the event and instead, subscribe to their semantics?
I discovered an exciting new way to manage event schemas that will blow your mind!
How can you prevent accidental breaking changes from creeping into your event schemas?
You can detect and stop breaking changes:
* At runtime, when the events are ingested;
* During development, when schema changes are made;
* Or a combination of both!
In this article, let’s look at three approaches you should consider.
Event-driven architectures encourage loose coupling.
But we are still bound by lessor forms of coupling such as schema coupling. And here lies a question that many students and clients have asked me:
“How do I version my event schemas?”
In this post, let’s run through some common approaches and why they all suck to some degree and the two most important decisions you need to make.
“Lambdalith” refers to deploying monolithic applications using AWS Lambda. This is typically associated with (but not limited to) building serverless APIs.
With a Lambdalith, a single Lambda function handles all the routes in an API. You can use Lambda Function URLs [1] or put the function behind a greedy path in API Gateway.
This contrasts with the “function per endpoint” approach, where a different Lambda function handles each API route.
Lambdaliths has been the source of intense debate in the serverless community. While I generally prefer the “function per endpoint” approach, I have adopted Lambdaliths where it makes sense.
In this post, let’s discuss the pros and cons of Lambdaliths and the nuances that are often overlooked.
Cognito M2M charges $2500 per million auth requests and other IDPs also charge a king’s ransom for M2M authentication!
Instead, check out these five alternatives to allow services to communicate securely with each other.
“Durable Execution” means a system can execute workflows reliably and remember progress even when failures occur. It typically involves persisting progress to avoid repeating side-effects on retries and allowing you to recover gracefully from failures.
It’s commonly associated with workflow orchestrators such as AWS Step Functions and AWS Lambda doesn’t support durability by itself.
But, as you will see in this post, there’s an easy way to add durable execution to Lambda, without needing to adopt a durable execution framework or rewriting your Lambda function as a Step Functions state machine.
And it only takes a few lines of code!
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.
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.