AWS EventBridge: Decoupling Microservices Without Building a Distributed Monolith

Microservices usually start reasonably. Service A calls Service B over REST. Then B needs something from C. Six months later there is a web of synchronous calls, and when C has a latency spike it surfaces as a 500 in A. You now carry the operational cost of many services with the failure characteristics of one process.

Event-driven architecture inverts the direction of that coupling. Services stop issuing commands to each other and start announcing what happened. Anyone who cares subscribes. EventBridge is the router that makes it practical on AWS.

The short version, if you only read one thing: use a custom bus, put SQS in front of anything fragile, attach a dead-letter queue per target, and treat your event schema as a contract nobody validates for you.

Why this actually decouples anything

In the synchronous version, a producer needs the consumer’s address, its API contract, and its retry semantics. Three pieces of knowledge, each of which becomes a reason to redeploy the producer when the consumer changes.

With a bus in the middle, the producer publishes a JSON object describing a state change and stops. It does not know whether there is one consumer, ten, or none. Adding a new downstream service becomes a new rule, with no change to the upstream code and no coordinated deploy.

Be clear-eyed about the trade, because it is a real one. You have removed a runtime dependency and added a schema dependency. The event shape is now the contract between services, and nothing enforces it. I come back to that below, because it is where this architecture bites hardest.

The three pieces

Event bus receives events. Rules are JSON filters attached to a bus. Targets are where a matching event goes, up to five per rule.

Native integrations cover most of what you need without glue code:

Pattern matching, which has exactly two rules

Rules are declarative JSON, and the evaluation is strict but small enough to hold in your head.

1
{
2
  "source": ["com.acme.orders"],
3
  "detail-type": ["OrderCreated"],
4
  "detail": {
5
    "status": ["pending", "processing"],
6
    "amount": [{"numeric": [">=", 1000]}]
7
  }
8
}

That reads as: from com.acme.orders, and type OrderCreated, and status is pending or processing, and amount at least 1000. Fields present on the event but absent from the pattern are ignored entirely.

Beyond exact matches you get prefix, suffix, anything-but, exists, numeric ranges, cidr, and $or for alternatives spanning different fields. Between them these remove a lot of if statements from consumer code, which is the point: filtering in the rule means the consumer never runs at all.

Use a custom bus

Every account has a default bus, and every AWS service event lands on it. CloudTrail, EC2 state changes, all of it. Publishing your domain events there means your rules evaluate against that firehose, and your application traffic sits amongst infrastructure noise.

A custom bus also gives you a resource policy, so you can state exactly which accounts and roles may publish. In a multi-account setup that is how a workload account publishes into a shared-services bus without being given broad permissions.

Schemas are the part that will hurt you

An event shape is an API. If producers change it freely, consumers break, and they break quietly, because a rule that no longer matches does not error. It simply stops firing.

The envelope is fixed; your data lives in detail:

1
{
2
  "version": "0",
3
  "id": "abc12345-6789-0def-1234-567890abcdef",
4
  "detail-type": "OrderCreated",
5
  "source": "com.acme.orders",
6
  "account": "123456789012",
7
  "time": "2026-11-03T12:34:56Z",
8
  "region": "eu-west-1",
9
  "resources": [],
10
  "detail": {"orderId": "ORD-2026-001", "amount": 150.0}
11
}

Rules that keep this survivable:

Errors, and where a dropped event goes

By default EventBridge retries a target for up to 24 hours with exponential backoff, and then discards the event. That last part is the one to internalise: without a dead-letter queue, a persistent failure means permanent data loss.

Attach a DLQ per target, and bound the retries so failures surface in minutes rather than a day:

1
import * as cdk from 'aws-cdk-lib';
2
import * as events from 'aws-cdk-lib/aws-events';
3
import * as targets from 'aws-cdk-lib/aws-events-targets';
4
import * as sqs from 'aws-cdk-lib/aws-sqs';
5

6
const dlq = new sqs.Queue(this, 'TargetDLQ', {
7
  retentionPeriod: cdk.Duration.days(14), // maximum, and you want it
8
});
9

10
const rule = new events.Rule(this, 'BillingEvents', {
11
  eventBus: customBus,
12
  eventPattern: {source: ['com.acme.billing']},
13
});
14

15
rule.addTarget(
16
  new targets.LambdaFunction(consumer, {
17
    deadLetterQueue: dlq,
18
    // Default is 24h / 185 attempts. Failing fast into the DLQ is usually
19
    // better: you find out today rather than tomorrow.
20
    maxEventAge: cdk.Duration.hours(2),
21
    retryAttempts: 5,
22
  }),
23
);

When a target wants a different shape from the event envelope, use an input transformer rather than writing an unwrapping Lambda:

1
rule.addTarget(
2
  new targets.SfnStateMachine(workflow, {
3
    input: events.RuleTargetInput.fromObject({
4
      orderId: events.EventField.fromPath('$.detail.orderId'),
5
      amount: events.EventField.fromPath('$.detail.amount'),
6
    }),
7
  }),
8
);

Archive and replay, the feature worth setting up before you need it

A bug ships on Friday. The consumer silently drops 500 events over the weekend. In a synchronous system you would be reconstructing those requests from logs and database backups.

With an archive on the bus, you fix the consumer, deploy, and replay the window.

Two details make this safe. Replayed events carry a replay-name field, so a consumer can tell a replay from live traffic and skip side effects like sending email or charging a card. And EventBridge adds a managed rule preventing replayed events from being re-archived, so you cannot create a storage loop.

A layout that keeps this manageable

The two directories worth arguing for are events/schemas, because putting the contract in version control makes a breaking change visible in review, and contract-tests, which assert a producer’s event still satisfies each consumer’s pattern. That test is what turns the silent-rule failure into a red pipeline.

Frequently Asked Questions

References

• What is Amazon EventBridge
• Event patterns in EventBridge
• Content filtering in event patterns
• Event buses
• Rule targets
• Input transformation
• Event retry policy and dead-letter queues
• Archive and replay events
• EventBridge schema registry
• Code bindings from schemas
• EventBridge quotas
• EventBridge pricing
• Reducing custom code with advanced rules (AWS Compute Blog)