Intermediate 20 min read

API Gateway and Event-Driven Architecture

By the end of this lesson, you'll be able to:

Explain API Gateway's role in front of Lambda, at a beginner level
Distinguish synchronous invocation from asynchronous invocation with a concrete example of each
Describe the event bus/producer/rule/target shape of an event-driven pattern such as EventBridge

Prerequisites: "Writing and Deploying Lambda Functions"

API Gateway: an HTTP front door for Lambda

Amazon API Gateway exposes an HTTP endpoint that clients can call, and routes matching requests to a backend — commonly a Lambda function. At a beginner level, API Gateway's job covers: request routing (matching a path and method to the right backend), integration with that backend (passing the request through, in this case to Lambda, and returning its response), and operational concerns like throttling (limiting how much traffic reaches the backend) and authentication/authorization (deciding who's allowed to call a given route at all — not every API should default to being open to anyone).

Diagram showing a client sending an HTTPS request to a fictional POST /registrations endpoint on API Gateway, which invokes a Lambda function, which reads or writes an item in DynamoDB, with the response traveling back through the same path. — This request/response shape — client, API Gateway, Lambda, data store — recurs throughout the rest of this module.

This lesson doesn't walk through every API Gateway feature or administration screen — the beginner-level goal is recognizing this shape (client → API Gateway → Lambda) as the standard way to expose application logic over HTTP without managing a web server.

Synchronous versus asynchronous invocation

This distinction matters throughout the rest of this module:

Synchronous invocation — the caller waits for Lambda to finish and receives the result or an error directly. An API Gateway request is exactly this: the client is still waiting on the other end of the HTTP connection.
Asynchronous invocation — the event is accepted, and Lambda processes it separately; the producer only learns that the event was accepted, not the eventual outcome of processing it.

Side-by-side diagram showing a synchronous invocation where a caller waits and receives a result or error directly, versus an asynchronous invocation where a producer only receives confirmation the event was accepted, with processing and retry or failure handling happening separately. — Retry and failure handling differ by invocation type and integration — there is no single rule that applies everywhere.

This lesson deliberately avoids stating one universal retry policy — exactly how retries and failures are handled depends on which service invoked the function and how, a detail worth checking against the specific integration in question rather than assuming it matches every other one.

Event-driven architecture: producers, an event bus, rules, and targets

Beyond a direct API call, AWS supports a broader event-driven pattern, where services react to events without being directly wired together. Amazon EventBridge is AWS's event bus service, built around a few concepts:

A producer — something that generates an event (an AWS service, or your own application).
The event bus — where events are published.
A rule — a filter that matches specific events based on their content.
A target — where a matching event is sent, such as a Lambda function.

Conceptually: Service or application → EventBridge → Rule → Lambda. This lets services stay decoupled — a producer doesn't need to know which Lambda functions (if any) are listening for its events; it just publishes them, and EventBridge routes matching events to whichever targets are currently configured to receive them. This lesson introduces the shape rather than every event-pattern-matching detail EventBridge supports.

Exercise

A web client needs to make an HTTP request that runs application logic and returns a result immediately, without the client's own team managing a web server. Which two-service architecture from this lesson fits, and is the resulting invocation synchronous or asynchronous? Explain why.

Show hint

The client is waiting for a direct response — that's the defining feature of one of the two invocation types this lesson covered.

API Gateway and Event-Driven Architecture Quiz

1. A web client needs to make an HTTP request that triggers application logic and waits for a result, without managing a web server. Which architecture best fits?

API Gateway routing the request to a Lambda function EventBridge publishing the request as an asynchronous event Uploading the request as a file to S3 Storing the request directly in DynamoDB with no compute involved

2. An asynchronous Lambda invocation lets the producer immediately know whether the eventual processing succeeded.

True False

3. The service commonly used to expose an HTTP endpoint in front of Lambda is Amazon ______.

Show hint

It's the service this lesson introduces as Lambda's HTTP front door.

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

Amazon API Gateway exposes an HTTP endpoint that routes requests to a Lambda function synchronously, returning a result directly to the caller; other AWS services can invoke Lambda asynchronously instead, where the producer only learns that an event was accepted, and event-driven services like EventBridge route events from producers to targets through configurable rules.

❬ Previous Next ❭