Serverless Apps: A Simple Design and Python Example

Serverless does not mean there are no servers. It means a provider manages more of the server work for you.

One common form is a function. An event starts a small piece of code. The platform runs it and returns a result. Events can come from HTTP requests, a queue or a schedule.

Follow a simple request

1. A browser sends a request to an API endpoint.
2. The gateway passes an event to the function.
3. The function checks the input and does its work.
4. It returns a result to the gateway.
5. The gateway responds to the browser.

On AWS, API Gateway and Lambda can fill these roles. Other providers have their own services and event formats.

A complete local handler example

Save this as lambda_function.py. It is written for an API Gateway HTTP API proxy-style event:

"""Example for an API Gateway HTTP API Lambda proxy integration."""
import json


def lambda_handler(event, context):
    query = event.get("queryStringParameters") or {}
    name = str(query.get("name", "reader"))[:80]
    return {"statusCode": 200,
            "headers": {"content-type": "application/json"},
            "body": json.dumps({"message": f"Hello, {name}!"})}


if __name__ == "__main__":
    print(lambda_handler({"queryStringParameters": {"name": "Sam"}}, None))

Run python lambda_function.py. The body should contain Hello, Sam!. This tests the Python handler only. It does not create an API Gateway endpoint or deploy a Lambda function.

For this file, the configured Lambda handler name would be lambda_function.lambda_handler. A real deployment also needs the correct event integration, runtime, role and logs.

Events need clear rules

The handler receives data, not a trusted instruction. Check required fields and decide what an invalid event should return.

Different triggers have different shapes. An event from object storage is not the same as an HTTP event. Do not copy a handler without checking its trigger.

Keep durable data outside the function

Do not rely on a global Python variable to store a user’s order. A function environment can be reused, replaced or run alongside other copies.

Store lasting data in a suitable database or storage service. Give the function’s role only the access it needs.

Retries can repeat work

Some event sources deliver more than once. A retry can happen after a timeout even if part of the work succeeded.

If an event creates an order, use a stable event or order ID. Record that ID in a durable store with an atomic check. A repeated event can then return the earlier result instead of creating a second order. This is called idempotency.

Cold starts, limits and costs

A cold start is extra work to prepare a new execution environment. Its effect depends on the runtime, packages, configuration and traffic.

Check time limits, memory, concurrency and payload sizes. Keep slow work out of an HTTP request when a queue and background worker are a better fit.

Serverless is not always cheaper. Include the gateway, database, logs, network traffic and any minimum or reserved capacity in your estimate.

How to release safely

Test the handler, build one package and keep its version. Use separate test and production settings. Watch errors and latency after release. Keep a known working version and a clear way to route traffic back.

Do not treat “the upload succeeded” as proof the app works. Test an actual event and its result.

Practice

Add a test for an event with no query fields. Add another with queryStringParameters set to null. Explain why both should return a useful answer.

Next, draw a file-upload flow: upload event, queue, worker and result storage. Mark where you would check duplicates and where failures would be recorded.

Official references and further reading

Reviewed on 25 October 2026. Tools change, so check the official documentation for the version you use.

• AWS Lambda Python handlers
• Lambda best practices

DevOps learning roadmap · All DevOps & Cloud tutorials