After years of building Lambda-based systems, I've seen the full spectrum: no tests at all, tests that mock everything and catch nothing, and test suites so slow they're never run in CI. I've made all those mistakes myself.

This post discusses the approach I find most effective. It's not about comparing frameworks or libraries; rather, it's the setup I consider best for incorporating tests into a serverless application.

The Problem With "Just Test Your Functions"

The most common advice you'll hear is "Lambda functions are just functions — they're easy to test." And that's technically true. You can, and honestly should, add unit tests for each lambda in isolation.

On the other hand, though, the problem is that most of the interesting bugs in serverless systems don't live inside the function logic. They live at the edges:

• The IAM permission that works locally but not in prod

• The SQS message that's shaped differently than you expected

• The DynamoDB expression that silently returns nothing instead of erroring

• The S3 event notification that fires but your handler throws before processing it

• The Lambda is in a loop because the file is being pushed and read from the same S3

If your entire test strategy is mocking aws-sdk and asserting on return values, you're absolutely missing out on potential bugs.

The Three-Layer Model I Actually Use

I think about serverless testing in three layers, and I'm deliberate about what each one covers.

Layer 1: Unit Tests — Test the Logic, Not the Infrastructure

Unit tests should be fast, isolated, and abundant. But "isolated" doesn't mean "mock everything."

Here's the distinction I make: I don't mock my dependencies. I replace them with Fakes.

A mock is a hollow stub — you tell it what to return, it returns exactly that, and it never pushes back. A Fake is a real, working implementation of the same interface, just without the infrastructure. It has actual logic: it stores items in memory, enforces constraints, and throws an error on invalid input. It behaves like the real thing, just without DynamoDB behind it.

// The interface both the real implementation and the Fake satisfy
interface UserRepository {
  save(user: User): Promise<void>;
  findById(id: string): Promise<User | null>;
}

// The Fake — real behavior, no infrastructure
class InMemoryUserRepository implements UserRepository {
  private store = new Map<string, User>();

  async save(user: User): Promise<void> {
    if (!user.id) throw new Error('User must have an id');
    this.store.set(user.id, user);
  }

  async findById(id: string): Promise<User | null> {
    return this.store.get(id) ?? null;
  }
}

Now your unit tests use InMemoryUserRepository and they actually mean something. If your handler calls findById with the wrong ID, the Fake returns null — just like DynamoDB would. You're testing real behavior, not scripted responses.

describe('processOrder', () => {
  it('should reject orders with no items', async () => {
    const repo = new InMemoryUserRepository();
    const result = await processOrder({ items: [] }, repo);

    expect(result.success).toBe(false);
    expect(result.error).toBe('ORDER_EMPTY');
  });

  it('should not persist an order that fails validation', async () => {
    const repo = new InMemoryUserRepository();
    await processOrder({ items: [] }, repo);

    // The Fake lets us assert on actual state, not on whether a method was called
    expect(await repo.findById('order-123')).toBeNull();
  });
});

Fast. Deterministic. And honest about what your code actually does.

The payoff of Fakes comes later: you can run contract tests that exercise both the Fake and the real implementation against the same suite. If DynamoUserRepository and InMemoryUserRepository both pass the same contract tests, you know the Fake is trustworthy — and your unit tests are as meaningful as your integration tests.

// The contract — runs against both implementations
function userRepositoryContract(makeRepo: () => UserRepository) {
  it('should persist and retrieve a user', async () => {
    const repo = makeRepo();
    await repo.save({ id: 'u1', email: 'test@example.com' });
    expect(await repo.findById('u1')).toMatchObject({ id: 'u1' });
  });

  it('should return null for unknown IDs', async () => {
    const repo = makeRepo();
    expect(await repo.findById('nonexistent')).toBeNull();
  });
}

// Run the contract against both
describe('InMemoryUserRepository', () => userRepositoryContract(() => new InMemoryUserRepository()));
describe('DynamoUserRepository', () => userRepositoryContract(() => new DynamoUserRepository(client, 'users-test')));

This pattern does require more upfront design — your dependencies need to be behind interfaces, and you need to maintain the Fakes. That's not free. But it pays back in test confidence and, honestly, in better code architecture. If something is hard to Fake, it's usually a sign that the dependency boundary is wrong.

What I cover at this layer:

• Business logic and domain rules

• Input validation and error handling

• Event parsing and transformation

• Edge cases and branching paths

What I don't bother covering here:

• Whether the DynamoDB call actually works

• Whether my IAM role has the right permissions

• Whether the Lambda timeout is long enough

Layer 2: Integration Tests — Test the Real AWS Interactions

This is where most projects fall apart. Developers either skip integration tests entirely (dangerous) or try to run them against real AWS (slow and expensive).

My approach: run integration tests against a local AWS emulator during development and CI, and run a smaller set against a real staging environment before merging to main.

For local emulation, I've been working on tooling around this exact problem — more on that in a future post. For now, the important thing is the principle: your integration tests should exercise actual AWS API calls, not mocked ones.

What I cover at this layer:

• DynamoDB reads and writes (real expressions, real shapes)

• SQS send and receive (including batch behavior)

• S3 put/get/delete

• EventBridge publish and filtering rules

• Any service-to-service interaction within your system

// Example: Real DynamoDB interaction, real data shape
describe('UserRepository', () => {
  it('should persist and retrieve a user by ID', async () => {
    const repo = new UserRepository(dynamoClient, 'users-test');
    const user = { id: 'user-123', email: 'test@example.com', createdAt: Date.now() };

    await repo.save(user);
    const retrieved = await repo.findById('user-123');

    expect(retrieved).toMatchObject(user);
  });
});

Yes, this test talks to a database. That's the point.

Layer 3: E2E Tests — Test the System, Not the Pieces

End-to-end tests in serverless are expensive to run and slow to write. I keep this layer thin on purpose.

My rule: one E2E test per critical user journey, not per endpoint.

For a typical API, that might mean:

• A user can sign up and receive a confirmation email

• A payment can be initiated and the webhook handled correctly

• A file upload triggers processing and the result is available

These tests deploy real infrastructure (or use a dedicated staging environment) and exercise the full stack. They're not run on every commit — they run on every PR merge to staging, and before every production deploy.

What I cover here:

• Critical paths that involve multiple Lambda functions

• Event-driven flows (trigger → process → result)

• Anything where the cost of failure is high

The Testing Stack

Here's what I actually use, without the fluff:

• Jest — test runner, all layers

• @sls-testing/jest — utilities I built specifically for Lambda testing (event factories, context mocks, assertion helpers)

• Local emulator — for integration tests in CI (more on this soon)

• Real AWS staging — for E2E tests, isolated account or dedicated stage

I'm not going to tell you that you need every tool in this list. Start with Jest and clean unit tests. Add integration tests when you start seeing production bugs that your unit tests didn't catch. Add E2E tests when your system is complex enough to have meaningful user journeys.

Common Mistakes I See (And Made)

1. Mocking the entire AWS SDK

You end up testing that you called putItem with certain parameters. DynamoDB doesn't care about your test — and neither should you. Test the outcome, not the invocation.

2. Testing the framework, not your code

If half your tests are verifying that API Gateway parses the request correctly, you're wasting time. API Gateway already has tests. Yours should cover what happens after the parsing.

3. Coupling tests to infrastructure details

If a test breaks because you renamed a DynamoDB table or changed an environment variable, that's a configuration problem, not a testing problem. Keep infrastructure config out of your test logic.

4. No tests on the async paths

Synchronous request/response flows are easy to test. Async flows — SQS consumers, EventBridge subscribers, Step Functions — are where people give up. Don't. These paths often carry your most critical business logic.

The Bottom Line

My testing strategy in one sentence: unit test the logic, integration test the AWS interactions, E2E test the user journeys — and be ruthless about keeping each layer small and honest.

You don't need 100% coverage. You need the right coverage in the right places.

If this resonated, I'm working on a full ebook on the topic — Testing Serverless Applications (TDD in the Real World) — that goes much deeper on each layer, including contract testing, load testing, and infrastructure testing with CDK. More on that soon.

In the meantime, if you have questions or want to share how you're approaching this, reply to this post or find me on [LinkedIn / X / wherever].

Enjoyed this? The Practical Serverless newsletter covers this kind of stuff every week — no filler, just real serverless patterns from the field.

AI Disclaimer: AI has been utilized to refine the text. The experiences and content are my own.

But still, we are talking about technology, and to be more precise, about software architecture, and an important part of that is knowing the trade-offs for choosing the right tool for your problem.

Serverless is great, but it doesn't solve all the problems though.

The trade-offs

Let's be real about a few things.

Cold starts hurt in specific situations. If you're building a public-facing API where a small percentage of requests hitting an uninitialized container is acceptable, you'll probably never notice. But if you're building a latency-sensitive application, you will definitely not want to deal with cold starts. It has some workarounds, like Provisioned Concurrency, which solves the problem, but obviously, it adds cost.

Lambdas also have their limitations. You can't run it for over 15 minutes, and the max memory is 10GB, for example.

The observability will be more complicated. With serverless, you're dealing with distributed, short-lived functions that can scale to hundreds of concurrent executions in seconds. Debugging that without proper instrumentation — structured logs, distributed tracing, alerting — is a bad time.

And obviously, there's lock-in. Using managed AWS services is genuinely one of the best parts of going serverless, and also the thing that makes migration expensive if you ever need it. You're making that trade whether you're aware of it or not.

Know these going in. Build with them in mind. Serverless is still worth it — just not blindly.

When Lambda is the wrong choice

Talking about trade-offs is useful, but let's make it concrete. Here are real scenarios where you should think twice before reaching for Lambda.

You need long-running, stateful processes. Video encoding, large data migrations, ML model training — anything that may hit the 15-minute limit or needs to maintain state across steps is a bad fit. You'll end up doing gymnastics with Step Functions to work around Lambda's limits, and at some point, you have to ask: Is this still simpler than just running a container?

Your workload is constant and predictable. Serverless shines when traffic is spiky or unpredictable. If you have a service that runs at steady, high volume 24/7, the pay-per-invocation model stops being cheap. At scale, a reserved EC2 instance or a Fargate service is often more cost-effective. Run the numbers before you commit.

Latency is non-negotiable. Cold starts are manageable in most cases, but if you're building something like a high-frequency trading system or a real-time gaming backend where every millisecond matters, serverless is not your friend. Provisioned Concurrency helps, but it also chips away at the cost model that made serverless attractive in the first place.

Your team is already struggling with observability. Lambda doesn't create observability problems, but it amplifies existing ones. If your team doesn't have solid practices around logging, tracing, and alerting, going serverless will make debugging feel like chasing ghosts. Get the foundation right first.

You're lifting and shifting a monolith. Taking an existing monolithic application and deploying it as a single Lambda function is almost never a good idea. You get the complexity of serverless without any of the benefits. If you're migrating, the work is in decomposing the application, which probably is not worth changing where it runs.

Serverless is more than Lambda

If you've been following the serverless conversation online — or even if you've read my book, From Zero to Production with AWS Lambda — you'd be forgiven for thinking serverless is mostly about Lambda. Lambda gets the blog posts, the talks, the hot takes. But Lambda is just one piece of a much bigger picture.

Serverless is a model, not a service. It's about offloading infrastructure management so you can focus on your business logic. Lambda does that for compute, but the same principle applies across your entire stack.

DynamoDB is serverless. You don't manage servers, you don't provision capacity upfront, you just store data and pay for what you use. The same applies to API Gateway, S3, SQS, SNS, and EventBridge — it's all serverless. This can go on and on.

There are serverless options to enhance your stack, and some can even replace Lambdas. For instance, if you have a long-running process or predictable high-volume traffic, Fargate is a great choice. You still avoid managing servers, enjoy automatic scaling, and pay only for what you use. It's serverless, just not Lambda.

When pieces work together, that's when you unlock the real power. A file lands in S3, triggers a Lambda function, which publishes an event to EventBridge, which fans out to multiple SQS queues, each processed by a different Lambda. A heavy processing job gets handed off to Fargate. No servers. No clusters. No ops team babysitting instances at 3 am.

That's the architecture worth understanding. Lambda is the most visible part of it, but building serverless applications means thinking about the whole ecosystem — and knowing which managed service fits each job, Lambda or otherwise.

I built @sls-testing to stop that. It provides typed, composable one‑line builders that give sensible defaults, automatic marshaling, and easy overrides so your tests only express what matters.

The payoff: what used to be a 30–60 line fixture becomes a single builder call — cutting test setup by roughly 90%. Below, I’ll show before/after examples, the API surface, and how it handles common event types (API Gateway, SQS, S3, DynamoDB Streams).

Here's what the before/after looks like.

The Problem: 60 Lines to Say "POST /users"

Testing a Lambda handler behind API Gateway v2 requires an APIGatewayProxyEventV2 object. Here's the minimum viable event most teams copy around:

const event = {
  version: '2.0',
  routeKey: '$default',
  rawPath: '/users',
  rawQueryString: '',
  headers: {
    'content-type': 'application/json',
    'accept': 'application/json',
  },
  isBase64Encoded: false,
  body: JSON.stringify({ name: 'Lucas' }),
  requestContext: {
    accountId: '123456789012',
    apiId: 'test-api-id',
    domainName: 'test-api-id.execute-api.us-east-1.amazonaws.com',
    domainPrefix: 'test-api-id',
    http: {
      method: 'POST',
      path: '/users',
      protocol: 'HTTP/1.1',
      sourceIp: '127.0.0.1',
      userAgent: 'jest',
    },
    requestId: 'some-uuid-here',
    routeKey: '$default',
    stage: '$default',
    time: '01/Jan/2024:00:00:00 +0000',
    timeEpoch: 1704067200000,
  },
}

That's 30+ lines for an event where the only things you actually care about are the method, path, and body. The rest is structural noise — correct enough to not crash, meaningless to your test.

Now multiply that by every event type in your service. SQS needs messageId, receiptHandle, attributes, eventSourceARN. S3 needs bucket, key, responseElements, userIdentity. DynamoDB Streams need marshalled AttributeValue maps where "hello" becomes { S: "hello" } and 42 becomes { N: "42" }.

Most teams solve this one of three ways:

1. Copy-paste JSON fixtures — Brittle, verbose, drift from reality over time.

2. Hand-roll factory functions — Every team writes their own, slightly differently, and they're never complete.

3. Skip testing — The honest answer when the setup cost exceeds the perceived value.

None of these are good.

The Solution: Express Intent, Not Structure

With @sls-testing/core, the same test becomes:

import { buildApiGatewayEvent } from '@sls-testing/core'

const event = buildApiGatewayEvent({
  method: 'POST',
  path: '/users',
  body: JSON.stringify({ name: 'Lucas' }),
})

Three lines. Same fully-typed event. Every field you didn't specify gets a sensible default — a real-looking request ID, a timestamp, valid ARNs. The TypeScript types come from @types/aws-lambda, so your IDE autocompletes every field if you need to override something specific.

The pattern is the same across all six event types:

// SQS — bodies auto-serialized, each record gets a unique messageId
const sqsEvent = buildSQSEvent({
  records: [
    { body: { orderId: 'abc-123', amount: 99.9 } },
    { body: { orderId: 'def-456', amount: 49.9 } },
  ],
})

// S3 — just bucket and key, everything else filled in
const s3Event = buildS3Event({
  bucket: 'uploads',
  key: 'images/photo.png',
})

// DynamoDB Streams — plain objects auto-marshalled to AttributeValue
const streamEvent = buildDynamoDBStreamEvent({
  records: [{
    eventName: 'INSERT',
    keys: { id: 'abc' },
    newImage: { id: 'abc', name: 'Lucas', count: 42 },
  }],
})

// EventBridge
const ebEvent = buildEventBridgeEvent({
  source: 'app.orders',
  'detail-type': 'OrderPlaced',
  detail: { orderId: 'abc-123' },
})

// SNS
const snsEvent = buildSNSEvent({
  records: [{ message: { action: 'notify' } }],
})

The DynamoDB builder is where the savings are most dramatic. Manually constructing a DynamoDBStreamEvent with marshalled values is easily 40-50 lines. The builder does the marshalling for you — pass { count: 42 } and it becomes { N: "42" } automatically.

Beyond Events: Lambda Context

Events are half the story. Your handler also receives a Context object, and AWS's type definition has 12 fields. Most tests either ignore it (handler(event, {} as any) — hello, runtime crash) or build an incomplete mock.

import { buildLambdaContext } from '@sls-testing/core'

const context = buildLambdaContext({
  functionName: 'order-service-dev-processOrder',
  memoryLimitInMB: '512',
  remainingTimeOverride: 5000,
})

context.getRemainingTimeInMillis() // 5000 — actually works

Every field has a default. getRemainingTimeInMillis() returns the value you configure. The awsRequestId is a real UUID. The logGroupName derives from the function name. It's a real Context object, not a type-cast empty object.

Assertions That Speak Serverless

The companion package @sls-testing/jest adds custom Jest matchers that understand Lambda response shapes:

import '@sls-testing/jest'

const result = await handler(event, context)

// Status code assertions
expect(result).toHaveStatusCode(200)
expect(result).toBeSuccessfulApiResponse()  // any 2xx
expect(result).toBeClientError()             // any 4xx
expect(result).toBeServerError()             // any 5xx

// Deep response matching with asymmetric matchers
expect(result).toMatchLambdaResponse({
  statusCode: 201,
  body: { userId: expect.any(String) },
  headers: { 'content-type': 'application/json' },
})

// SQS batch response assertions
expect(result).toHaveNoFailedMessages()
expect(result).toHaveFailedMessage('msg-id-2')

toMatchLambdaResponse automatically parses the JSON body for comparison — you don't need to JSON.parse(result.body) in every test. Asymmetric matchers like expect.any(String) work inside the body, so you can assert structure without pinning every generated value.

The error messages are designed for Lambda. When toHaveStatusCode fails, it shows you both the expected and actual status codes plus the response body — because when a Lambda returns 500 instead of 200, the first thing you need is the error message, not a generic "expected 200 but received 500".

What the Numbers Actually Look Like

Let me do the math on a real scenario — a service with three Lambda functions (API Gateway handler, SQS consumer, DynamoDB Stream processor), each with 3-4 test cases.

Without @sls-testing

With @sls-testing

That's roughly a 90% reduction in test setup code. But the real win isn't the line count — it's the cognitive load. When a test file is 80% fixture and 20% assertion, you can't see what's being tested. When it's 20% setup and 80% assertion, the intent is obvious.

Design Decisions

A few choices I made that shaped the library:

Sensible defaults, full override. Every builder returns a complete, valid event with zero arguments. Pass a DeepPartial override to change any field. This means the simple case is one line, but you can still construct precise edge cases when you need to test specific header combinations or malformed payloads.

Auto-serialization. SQS bodies and SNS messages are automatically JSON.stringify'd. DynamoDB images are automatically marshalled. You pass plain objects; the builder handles the format Lambda actually receives.

Framework-agnostic core. @sls-testing/core works with Jest, Vitest, Mocha, or any test runner. The Jest-specific matchers are a separate package. Vitest adapters are planned for v2.

Types from the source. All event types come from @types/aws-lambda — the community-maintained definitions that match the actual AWS runtime. No custom type definitions that could drift.

Unique identifiers per call. Every buildSQSEvent() call generates unique messageIds, every context gets a unique awsRequestId. This prevents subtle test pollution where two tests accidentally share the same ID.

Getting Started

npm install @sls-testing/core @sls-testing/jest --save-dev

Add the Jest setup (or import per file):

{
  "setupFilesAfterEnv": ["@sls-testing/jest"]
}

Write a test:

import { buildApiGatewayEvent, buildLambdaContext } from '@sls-testing/core'
import '@sls-testing/jest'
import { handler } from './handler'

it('creates a user', async () => {
  const event = buildApiGatewayEvent({
    method: 'POST',
    path: '/users',
    body: JSON.stringify({ name: 'Lucas' }),
  })

  const result = await handler(event, buildLambdaContext())

  expect(result).toHaveStatusCode(201)
  expect(result).toMatchLambdaResponse({
    body: { name: 'Lucas', id: expect.any(String) },
  })
})

That's it. No fixture files. No factory functions. No as any casts.

What's Next

The library is at v1 and covers the six most common Lambda event sources. The roadmap includes:

• Vitest adapter — Same matchers, native Vitest integration

• Serverless Framework plugin — Bridge serverless.yml config into tests so function names, timeouts, and env vars stay in sync automatically

• More event types — Cognito triggers, CloudWatch Events, Kinesis

• Snapshot testing — Assert that response shapes haven't changed across deploys

• Error simulation — Builders for timeout, OOM, and cold start scenarios

The repo is at github.com/brognilucas/sls-testing. Contributions welcome — especially if you have event types you'd like to see supported.

Testing serverless applications shouldn't require more boilerplate than the business logic itself. If your test files are 80% fixture setup, something is wrong with the tooling, not with your tests.

As with everything in software, the database choice comes with trade-offs, and understanding what are those are extremely important. Scaling characteristics, connection handling and concurrency, latency, consistency and transactional needs, operational overhead, and pricing model are all factors to consider.

This article unpacks those trade-offs, compares common patterns (serverless‑native databases, managed relational options, caches, and streaming stores), and offers practical rules of thumb so you can pick a database that fits your application rather than creating new operational headaches. By the end, you’ll have a concise checklist to make the decision faster and more confidently.

Why database choice matters more in serverless

In traditional servers, database connections are opened once and reused across thousands of requests. Application instances are long‑lived and predictable. Serverless flips that model: functions spin up, live for seconds or minutes, and vanish. Each invocation may be a fresh process with no previous state, no persistent connection, and no guarantee of locality to previous requests. That changes the calculus: connection limits, cold‑start penalties, and per‑operation pricing matter far more than they did in long‑running servers.

A database that works well behind a long‑lived app can cause connection storms, latency spikes, or runaway costs when used directly from a fleet of ephemeral functions. The goal is to match your workload’s requirements (throughput, latency, consistency, transactions) with a storage option whose trade‑offs align with serverless behavior.

Key trade-offs to weigh

• Scaling characteristics: Does the database scale horizontally without connection limits or shard coordination that conflicts with ephemeral clients?

• Connection handling and concurrency: Can thousands of short‑lived connections be supported efficiently, or do you need a pooling/proxy layer?

• Latency: Are single‑digit‑millisecond reads required, or can you accept higher, variable latency?

• Consistency and transactions: Do you need strong ACID guarantees across multiple keys/tables, or is eventual consistency acceptable?

• Operational overhead: How much maintenance, tuning, backups, and failover handling will your team manage?

• Pricing model: Per‑operation, provisioned capacity, or storage‑centric billing—how do patterns of traffic (spiky vs steady) affect cost?

Common patterns and how they map to serverless

• Serverless‑native databases (e.g., serverless NoSQL or fully serverless managed stores):

  • Pros: Auto‑scaling, connectionless or HTTP/SDK access, fine‑grained billing, low operational overhead.

  • Cons: Weaker transactional guarantees or complex modeling for relational data; can be expensive at very high sustained throughput.

  • When to use: Spiky workloads, simple access patterns, evented architectures, or when you want minimal ops.

• Managed relational databases (serverless variants or provisioned RDS/Aurora/etc.):

  • Pros: Familiar SQL, strong transactions, complex queries.

  • Cons: Connection limits and scaling challenges; may require connection pooling (proxy, pooler, or Data API) and can incur cold‑start latency.

  • When to use: Applications that require ACID across multiple records or complex joins and cannot be re‑modeled easily.

• Caches and in‑memory stores (Redis, Memcached, or managed variants):

  • Pros: Extremely low latency for hot reads, useful for rate limiting, sessions, and ephemeral state.

  • Cons: Not a durable primary store (unless using persistence features), additional operational cost, eventual consistency with origin store.

  • When to use: Read‑heavy, low‑latency needs, offloading hotspots from a primary datastore.

• Streaming/append logs (Kafka, Kinesis, Pulsar, streaming databases):

  • Pros: Durable event delivery, great for event‑sourcing, async processing, and decoupling components.

  • Cons: Not a drop‑in replacement for arbitrary reads/transactions; requires different application patterns.

  • When to use: Event‑driven architectures, audit logs, long‑running workflows.

Practical rules of thumb

• If your functions open many short‑lived DB connections, use a serverless‑friendly datastore or a connection proxy. Don’t rely on direct DB connections from unpooled functions.

• For strong multi‑row/multi‑table transactions choose managed relational options—but consider a serverless (Data API) or pooled access pattern to avoid connection storms.

• For spiky traffic with bursty reads, prefer serverless‑native stores and caches; they scale on demand and bill for usage.

• If your app can tolerate eventual consistency, embracing key‑value or document models often reduces complexity and cost.

• Use streaming stores for durable event capture and decoupling; combine with a materialized view or read store for low‑latency queries.

• Measure cost at expected traffic patterns—serverless pricing can be higher for sustained, heavy throughput than for bursty, intermittent use.

Closing thoughts

Choosing a database for serverless shouldn’t be guesswork. Match your access patterns and operational constraints to the storage option whose trade‑offs you can live with, and use small experiments to validate latency, scaling, and cost under realistic load. This keeps serverless simple, where it should be—letting your team move faster without trading away reliability or spiraling costs.

Let's forget the object that you can access on the lambda, and think of its concept: what makes something an event, and not a command, or a message.

In serverless, I believe knowing this concept matters a lot. The whole ecosystem is built on a deeply event-driven model. EventBridge, SQS, SNS, DynamoDB Streams, and S3 notifications all depend on events.

In this post, we'll return to the basics. We'll explain what events really are, how they differ from commands and messages, and why these differences matter in every serverless system you create.

What is an event

A few years ago, during a talk by James Eastham, I learned something crucial: an event is a fact and cannot be undone. Exactly, you can't reverse an event. Consider writing a post for this blog; once you publish it, the action is irreversible. The post.published event has already been triggered.
You might wonder: if I delete the post, have I undone the action? Not quite. You haven't reversed the publication; instead, you've added another event to the sequence.

That's the essence of an event. In simple terms, an event represents an action that has occurred in the real world within your system.

What is a Command

If an event is something that has happened, a command is something you're asking to happen. It's a request, not a fact. And unlike events, commands can be rejected.

Think of it this way: when a user clicks "Publish" on your blog editor, your frontend might send a PublishPost command to your backend. That command can fail. The post might not meet validation rules, the user might not have the right permissions, or the system might be temporarily unavailable. The command is an intention, not a truth.

This distinction has real architectural consequences. Commands generally have an intended recipient. You don't broadcast a command to anyone who might be listening. You send it to the one service or function responsible for handling it. There's an implicit contract: someone is expected to act on it.

In serverless terms, an SQS queue carrying a ResizeImage instruction is a good example of a command channel. One producer, one consumer, one clear responsibility.

What is a Message

A message is the broadest of the three. Both events and commands travel as messages. The word "message" tells you about the transport, not the intent.

This is where a lot of confusion creeps in. Developers see SNS delivering a payload and call it "just a message." Technically, yes. But what matters architecturally is what's inside. Is it announcing something that happened, or requesting something to be done?

Getting that wrong leads to systems where consumers start making assumptions they shouldn't. A consumer that receives an event shouldn't be the one deciding whether the action was valid. That ship has sailed. But a consumer that receives a command absolutely should validate it before acting.

Why These Differences Matter in Serverless

In a distributed architecture, the distinction between events and commands changes how you design your application, how you deal with errors, and how do you handle a retry logic.

With events, every listener is an observer. They react to facts. If a user.registered event triggers a welcome email Lambda and that function fails, you don't "undo" the registration — you retry the email. The event remains true regardless.

With commands, the linesteners are executors. They own the outcome. A failed ProcessPayment command is not something you silently retry without careful thought. The intent hasn't been fulfilled, and that matters.

EventBridge is a great example of an event bus done right: it's designed around broadcasting facts to multiple consumers. SQS, on the other hand, lends itself naturally to commands. It's point-to-point, with visibility timeouts and dead-letter queues that reflect the expectation that someone must handle this.

Conclusion

Understanding the difference between events, commands, and messages is more than academic — it's foundational to building reliable, scalable serverless systems.

Events are immutable facts about things that have already happened; commands are intent to perform an action; messages are the vehicles that convey either. Treating them correctly changes how you design APIs, choose services, handle failures, and reason about system behavior.

Key takeaways and practical guidance:

• Name things clearly: events in past tense (e.g., post.published), commands as imperatives (e.g., createPost), messages as contextual envelopes.

• Model events as immutable facts: persist them, append rather than overwrite, and use them to drive downstream state and side effects.

• Use commands when you need explicit intent and control over execution (and choose queuing patterns that preserve ordering and retries).

• Expect duplicates and out-of-order delivery in distributed systems: make consumers idempotent and design for eventual consistency.

• Keep schemas explicit and versioned; consider a registry or strict contracts for producers and consumers.

• Pick the right tool for the job:

What is a DLQ?

Before explaining the importance of it, let's make sure we are aligned on what a DLQ is.

Dead Letter Queue, or simply DLQ, is a message queue used to store messages that could not be successfully processed by a consumer. When a message can't be successfully processed, regardless of the reason, instead of losing or keeping it, retrying forever, this message is redirected and stored in the DLQ.

Imagine it as a holding area for problem messages. Instead of letting failures vanish or stop your system, the DLQ catches them. This allows engineers to check, fix, and handle them later without affecting the main process.

Why use a DLQ?

Now that we understand what a DLQ is, let's talk about why you should use one and why not having one is a red flag in any event-driven or message-based architecture.

Prevent message loss.

Without a DLQ, a message that fails to be processed can simply disappear. Depending on your configuration, it might be discarded, leaving no trace of what went wrong. A DLQ ensures that no message is silently dropped. You can count on the fact that every failure is preserved and accounted for.

Avoid infinite retry loops.

Retries are great, and we should absolutely have them. But retries alone are not enough. If a message is fundamentally broken, for instance, with an invalid format or references data that no longer exists, it can lead to retrying it indefinitely, which wastes resources, is not cost-efficient, and potentially blocks other messages from being processed. A DLQ acts as the exit door for those unrecoverable failures.

Improved observability and debugging.

When a message lands in a DLQ, it presents an opportunity. You can examine the payload to understand what caused the failure and enhance your system. Without a DLQ, that context is lost, but with one, it provides a valuable feedback loop for your application's reliability.

A useful practice I've learned over the years is that you can use DLQ payloads for writing tests. This helps identify where errors occurred and serves as documentation for the fix.

Operational safety net

Systems fails that is a fact.

Sooner or later, either the network will be unreachable, the third-party service you're integrating with will go down, or perhaps a bug was introduced into your application and the previous payload isn't acceptable anymore.

A DLQ will provide architectural resilience and ensure that transient failures don't cause permanent data loss. Once the underlying issue is resolved, messages can be reprocessed from the DLQ as if nothing had happened.

In short, Build for Failure, Design for Resilience

Dead Letter Queues are a fundamental safety net for event-driven systems: they prevent silent failures, preserve the context needed for diagnosing issues, and allow teams to address problematic messages without disrupting normal processing. When paired with strong observability and clear operational playbooks, DLQs enhance the reliability and maintainability of event-driven systems.

Quick practical checklist:

• Define sensible retry limits and exponential backoff to ensure only truly problematic messages reach the DLQ.

• Capture detailed metadata (timestamps, error reasons, processing context) with each dead-lettered message.

• Monitor DLQ size and rate, setting alerts for spikes or stagnation.

• Provide tools and processes for safe reprocessing, manual inspection, and automated remediation.

• Treat DLQs as integral components in architecture reviews and tests.

Adopting DLQs turns failures into actionable insights, keeping your system resilient and operable under real-world conditions.

Lucas Brogni is a Senior Software Engineer with 10+ years of experience building distributed systems.