When we talk about event-driven architectures, we often focus on things like loose coupling, scalability and DDD. But under the hood, the way consumers receive events matters just as much. And it usually comes down to one of two models: push vs poll.
Your choice dictates what service(s) you use and how you handle errors.
So, in this article, let’s compare the two models and understand their pros & cons.
Serverful (i.e. paying for uptime) services like RDS makes working with ephemeral environments more difficult and poses a cost concern.
In this artcile, let’s see how Neon’s Serverless Postgres database solves this problem and how we can clone an existing database instantly by branching from it.
We will see how Neon differs from Aurora Serverless v2 and give you a step-by-step guide on how to use Neon with ephemeral environments in both your day-to-day feature development work, as well as in CI/CD pipelines.
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.
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.