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.
2024 was the year I got back and amongst the community, and it felt great to be back!
If numbers tell a story, then my 2024 numbers is the story of a busy bee :-P
– launched 2 MVPs for clients
– 52% newsletter open rate
– 350+ workshop students
– $10,000 wasted on ads ?
– 33 blog posts
– 353k blog views
– 255k blog visitors
– 13k newsletter readers
– 50 newsletter issues
– 31 public talks
– 16 podcast episodes, 17k listens, 26k views
– 34 YouTube videos, 130k views, 6500 hours watched
– 420 LinkedIn posts
– 8.9M LinkedIn impressions
– 71k reactions
– 6250 comments
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.