Serverless function handlers (AWS Lambda, Azure, GCP)

A serverless function is one handler method that the cloud runs on demand, in response to a request, a queue message, a file upload or a schedule.

🔎 Unravel this example

At a glance

Mental model

A taxi instead of owning a car.

What happens, in order

1AWS Lambda: implement RequestHandler<Input, Output> with handleRequest(input, context)The input type depends on the trigger (API Gateway request, SQS event, S3 event).
2Azure Functions use annotations: @FunctionName("hello") with @HttpTrigger, @TimerTrigger or @QueueTrigger on a parameterGoogle Cloud Functions implement HttpFunction or CloudEventsFunction.
3Each instance handles one event at a timeThe platform scales by creating more instances, and may freeze or discard them between calls.
4Initialisation code (clients, configuration) outside the handler method runs once per instance and is reused by later calls, which makes warm invocations fast

Remember

Cold starts are costly for the JVM (class loading, framework startup)
There is no guarantee of one invocation per event
A runtime process loads your class once and then loops: it long-polls the platform for the next event, deserializes it into your input type, calls the handler, and posts the result

Watch out

Creating SDK clients inside the handler on every callTreating events as exactly-onceHeavy framework startup for tiny functionsAssuming local files or memory survive between invocations

Example (highlighted lines explain it)

public class OrderHandler implements RequestHandler<SQSEvent, Void> {    private static final ObjectMapper MAPPER = new ObjectMapper();   // created once per instance    private static final OrderService SERVICE = OrderService.create();    @Override    public Void handleRequest(SQSEvent event, Context context) {        for (SQSEvent.SQSMessage message : event.getRecords()) {            SERVICE.process(message.getBody());        }        return null;    }}

line 1 uses RequestHandler, the core of Serverless function handlers (AWS Lambda, Azure, GCP)
line 2 created once per instance
line 6 uses SQSEvent, the core of Serverless function handlers (AWS Lambda, Azure, GCP)
line 7 uses SQSEvent, the core of Serverless function handlers (AWS Lambda, Azure, GCP)

Read the full explanation (about 2 min)

A serverless function is one handler method that the cloud runs on demand, in response to a request, a queue message, a file upload or a schedule. You do not run a server; the platform starts instances and bills per invocation.

A mental model

A taxi instead of owning a car. You only pay for a ride when you need one, but the first ride may wait while the taxi is called (cold start).

How it works

AWS Lambda: implement RequestHandler<Input, Output> with handleRequest(input, context). The input type depends on the trigger (API Gateway request, SQS event, S3 event).

Azure Functions use annotations: @FunctionName("hello") with @HttpTrigger, @TimerTrigger or @QueueTrigger on a parameter. Google Cloud Functions implement HttpFunction or CloudEventsFunction.

Each instance handles one event at a time. The platform scales by creating more instances, and may freeze or discard them between calls.

Initialisation code (clients, configuration) outside the handler method runs once per instance and is reused by later calls, which makes warm invocations fast.

Going deeper

Cold starts are costly for the JVM (class loading, framework startup). Keep the package small, avoid heavy frameworks, consider SnapStart or GraalVM native images, and create SDK clients statically, not per call.

There is no guarantee of one invocation per event. Queue and stream triggers retry and deliver at least once, so handlers need to be idempotent; batch triggers should report partial failures instead of failing the whole batch.

Functions are time limited (Lambda up to 15 minutes) and have limited memory and no local state. Persist state externally and keep each call short.

Under the hood

A runtime process loads your class once and then loops: it long-polls the platform for the next event, deserializes it into your input type, calls the handler, and posts the result. Frozen environments keep static fields and open connections between calls, which is why reusing clients works but also why stale connections can fail after a long freeze.

Common mistakes

Creating SDK clients inside the handler on every call.
Treating events as exactly-once.
Heavy framework startup for tiny functions.
Assuming local files or memory survive between invocations.

How Unravel recognises it

When you paste code, Unravel looks for these signs of serverless function handlers (aws lambda, azure, gcp). Spotting them yourself is a good habit when you read unfamiliar code:

Annotations: @FunctionName @HttpTrigger @TimerTrigger @QueueTrigger @ServiceBusQueueTrigger
Types: RequestHandler RequestStreamHandler LambdaLogger APIGatewayProxyRequestEvent APIGatewayProxyResponseEvent APIGatewayV2HTTPEvent APIGatewayV2HTTPResponse SQSEvent S3Event SNSEvent ScheduledEvent DynamodbEvent KinesisEvent SQSBatchResponse and 4 more

Part of a learning path

Cloud-native Java · previous: Azure Service Bus, Event Hubs and Google Pub/Sub · next: Distributed tracing (OpenTelemetry)

Related concepts

AWS SQS and SNS messagingI/O and data Object storage SDKs (S3, Azure Blob, GCS)I/O and data

Frequently asked questions

What is Serverless function handlers (AWS Lambda, Azure, GCP)?

What are the most common mistakes with Serverless function handlers (AWS Lambda, Azure, GCP)?

Creating SDK clients inside the handler on every call. Treating events as exactly-once. Heavy framework startup for tiny functions. Assuming local files or memory survive between invocations.

How can I see Serverless function handlers (AWS Lambda, Azure, GCP) in real code?

Paste your own Java into Unravel and it will point out where serverless function handlers (aws lambda, azure, gcp) appears, explain how it works at the detail level you choose, and draw the flow of the code around it.