A New Rule, Not a Rewrite
Why EventBridge specifically was the right piece to reach for in the vehicle registration flow, tested against a feature that doesn't exist yet: corporate fleet registration.
Before going further into what actually reads from that SQS queue, it's worth pausing on a question the last post skipped past: why EventBridge specifically?
It's become the default choice in most serverless designs on AWS, and it's worth being honest about why, rather than treating it as a reflex. The real answer shows up when you stress-test the design against a feature that doesn't exist yet.
A feature that hasn't shipped
Say the team behind this fuel pass decides to support corporate fleets. A company with twenty delivery vehicles shouldn't have to register each one through the same personal-vehicle flow built so far, one owner, one vehicle, one government ID.
Corporate registrations probably need different verification entirely, checking business registration details instead of a personal ID, and likely routes through a different external system than the Department of Motor Traffic check used for individual owners.
Where that change actually lands
The current VehicleRegistered event already carries a payload. Adding one field to it, something like type: "personal" or type: "corporate", is enough to make this event self-describing.
From there, extending the system is a matter of writing one new event rule: if type equals corporate, route to a different target. That target could be a separate SQS queue feeding a completely different verification path.
ExpandEventBridge routes personal-vehicle events to the existing queue unchanged, and a new rule routes corporate events to a newly added queue and verification system
Nothing about the existing personal-vehicle path changes. The API Gateway route stays the same. The event schema gains a field, not a rewrite. The original event rule, and everything downstream of it, keeps running exactly as it did before this feature existed.
What this would look like without EventBridge
Picture the same feature request landing on a design that used a single Lambda function to handle all vehicle registrations, with an if/else branching on vehicle type inside the function body.
Adding corporate support there means opening that function, adding a branch, testing both the new logic and the old logic together, since they now share one deployable unit, and redeploying a function that was working fine for personal vehicles. Every future feature added to that function repeats the same risk: touching code a completely unrelated case depends on.
EventBridge turns "add a feature" into "add a rule." The blast radius of a new capability shrinks to exactly the new capability, instead of spreading into a shared function that everything else also happens to run through.
The connection point that was designed on purpose
This is the same idea the very first post in this series argued for, design the connection points before you need them, and it's worth seeing it work in an architecture that predates the feature it's now solving for.
Nobody designing the personal-vehicle flow needed to know corporate fleets were coming. What they needed was an event bus that made adding a new consumer cheap, so that when the requirement did show up, it was a rule, not a redesign.
With the extensibility question settled, it's time to go back to the actual queue: what reads the messages sitting in it, and how a queue in front of a slow, uncontrollable external system keeps that system from being the thing that breaks under load.
The Essentials
- Test an architecture against a feature it doesn't have yet. If a plausible future requirement forces a rewrite, that's a real weakness, not a hypothetical one.
- A self-describing event, carrying a
typeor similar field, is what makes content-based routing useful. Without it, EventBridge has nothing meaningful to filter on. - A new event rule has a blast radius of exactly the new feature. It doesn't touch the routes, functions, or queues an unrelated feature depends on.
- A shared function with growing branching logic has the opposite property. Every new case adds risk to every existing case that shares the same deployable unit.
- Designing for extensibility pays off exactly when an unplanned requirement shows up, which is, by definition, whenever it wants to.
Further Reading and Watching
Keep reading