A Lambda That Only Moves Data Is a Lambda You Don't Need

Wiring API Gateway straight into EventBridge for vehicle registration, skipping a transport-only Lambda, and using EventBridge's content-based filtering to route events into SQS.

August 29, 20264 min read6 / 12

Vehicle registration looks like registration's twin from the outside. A form, a click, an HTTP request behind CloudFront, exactly the shape the token-gated registration flow already used. Look one layer past the request, and it's a completely different pattern.

The form itself is simple: vehicle number, vehicle type, chassis number, fuel type, then a register button. Behind that button, the same external dependency from the very first post in this series shows up again, a check against the Department of Motor Traffic before the registration can succeed.

Three screens: personal details with the OTP challenge, vehicle registration, and the QR code issued once both steps succeed ExpandThree screens: personal details with the OTP challenge, vehicle registration, and the QR code issued once both steps succeed

That third screen, the QR code, is the payoff for everything covered so far: the OTP challenge from the passwordless frontend post, the DynamoDB write gated by the token check, and now this vehicle registration step. None of it is visible to the user. All they see is a form, a click, and eventually a code they can show at the pump.

Same front door, different path behind it

The request follows a familiar start. CloudFront receives it, routes it to an API Gateway origin, and API Gateway authorizes it against the Cognito user pool exactly the way the personal-details step does.

What happens next is where it diverges. Instead of an API Gateway route calling a Lambda function that calls a database, this route connects directly to Amazon EventBridge, no Lambda in between at all.

Why skip the Lambda

The obvious pattern would be a small Lambda function sitting between API Gateway and EventBridge, taking the request and calling the AWS SDK to publish it as an event. That's exactly the pattern this design skips.

The common pattern adds a transport-only Lambda between API Gateway and EventBridge. Direct service integration skips it, with no code and no cold start ExpandThe common pattern adds a transport-only Lambda between API Gateway and EventBridge. Direct service integration skips it, with no code and no cold start

A Lambda function that does nothing but forward data is a cost and a delay with no upside. API Gateway can integrate directly with EventBridge as a service integration, no custom code required, which means:

  • No Lambda execution cost for a function that adds no logic.
  • No cold start latency added to the request.

The rule worth keeping from this: a transport-only Lambda is a Lambda you can usually remove. The moment that function needs to actually transform the request, reshape the payload, enrich it with other data, add a Lambda back in. Until then, it's just overhead sitting between two services that can already talk to each other directly.

What EventBridge actually is

EventBridge is AWS's managed, serverless event bus. Producers publish events onto a custom bus, and any number of subscribers can receive them, a publish-subscribe system with automatic scaling built in.

That description alone makes it sound like SNS, another managed pub-sub service on AWS. The real difference is in how each one decides where an event goes.

  • SNS routes by topic. A publisher sends to a topic, and every subscriber to that topic gets the message.
  • EventBridge routes by content. An event rule can inspect the entire event, body, headers, metadata, and decide where it goes based on what's actually inside it.

For vehicle registration, that content-based routing is exactly the tool needed: route every event where the type is VehicleRegistered, and nowhere else.

Where the event actually goes

The event rule for VehicleRegistered events points at an SQS queue as its target. SQS is AWS's managed queue service, built to absorb a high volume of messages and hold them temporarily, up to 14 days at the maximum retention setting, 4 days by default.

That retention window matters more than it looks like. If whatever processes this queue is slow, backed up, or temporarily offline, the messages don't disappear. They sit in the queue until something is ready to read them. The producer, API Gateway through EventBridge, never has to know or care whether the consumer is keeping up in real time.

Put together, one HTTP request now results in: API Gateway validates the caller, forwards the event straight to EventBridge with no Lambda in the middle, an event rule matches on VehicleRegistered and routes it to SQS, and the message sits safely in the queue until something picks it up.

That queue is exactly where the interesting part starts. The DMT verification check is a call to an external system this design doesn't control and can't scale. The next post covers what reads from this queue, and how the queue itself protects that external system from getting more traffic than it can handle.

The Essentials

  1. A Lambda that only forwards data adds cost and latency for no benefit. Direct service integrations exist for exactly this case.
  2. API Gateway can integrate directly with EventBridge, no custom code needed for pure transport.
  3. EventBridge and SNS are both pub-sub, but they route differently. SNS routes by topic. EventBridge routes by content, using rules that inspect the whole event.
  4. SQS holds messages temporarily, up to 14 days by default settings allow. A slow or offline consumer doesn't lose data, it just catches up later.
  5. Decoupling with a queue means the producer never waits on the consumer. API Gateway's job ends the moment the event is queued.

Further Reading and Watching