The fan-out from 07-02 works, but it already shows a ceiling. mercadofresco-pedido-confirmado carries a single kind of fact; for PedidoCancelado, StockBajo and RepartoAsignado you would need one topic for each, each with its own subscriptions, its queue policies and its filters. Four topics today, twelve next year, and a map of subscriptions nobody knows how to draw in full. There are also facts that matter and that the shop does not publish —an instance of asg-mercadofresco-tienda changing state, Trusted Advisor spotting an idle resource, a deployment failing— and there is an open wound: when the analytics queue was misconfigured, the events from those hours were lost for ever.

Amazon EventBridge is AWS's serverless event bus. Instead of one channel per kind of fact, there is one bus where everything is published, and rules that decide where each event goes by looking at its full content. The sender knows nobody; the receiver does not depend on the sender; what joins them is a JSON pattern that can be changed without deploying code. And as a bonus, EventBridge receives events from over 200 AWS services out of the box and can archive and replay all of it.

In this lesson Luis creates bus-mercadofresco, designs the shop's business event catalogue, writes patterns of growing complexity, connects an API destination towards the warehouse ERP, schedules the nightly load into Redshift with cron, and finally puts to use the mercadofresco-carritos Streams that were introduced and left unused in 06-02.

Cost warning. EventBridge charges 1.00 USD per million custom events published; events from AWS services on the default bus are free. The archive costs per GB stored and replay is charged as a new publication: replaying a month of events goes through the till again. Pipes and Scheduler have their own pricing. At the end you have the cleanup. All data is fictitious.

1. SNS or EventBridge: the honest comparison
2. Buses: default, custom and partner
3. Anatomy of an event
4. MercadoFresco's event catalogue
5. Rules and event patterns
6. Targets and input transformation
7. Retries, maximum event age and DLQ per target
8. Events from AWS services
9. Scheduled rules and EventBridge Scheduler
10. Schema registry and code bindings
11. Event archive and replay
12. EventBridge Pipes and the mercadofresco-carritos Streams
13. Event-driven architecture: contracts and versioning
14. Observability and cost
15. Common mistakes and tips
16. Exercises
17. Conclusion

Both deliver a message to several destinations. The difference is in how much they know about the content and in what they bring out of the box.

The practical criterion. Use SNS when the pattern is pure fan-out of one fact to many destinations with simple filters, when minimum latency matters, when the volume is very high, or when the destination is a person (email, SMS). Use EventBridge when there are several event types over the same channel, when routing depends on the content, when you want to react to AWS or SaaS events, when you need archive and replay, or when the destination is an external API.

MercadoFresco ends up using both, and that is not a contradiction: bus-mercadofresco for the business events and for everything coming from AWS, and SNS for the high-volume fan-out of mercadofresco-pedido-confirmado —which already works and has lower latency— and for the notices to people from alertas-mercadofresco. In fact, an SNS topic can be the target of an EventBridge rule, which lets you combine them without duplicating anything.

An event bus is a named channel. There are three classes:

• Default bus (default). It exists in every region without creating it. This is where the AWS services' events from the account arrive automatically: EC2 state changes, Trusted Advisor results, ECS task transitions, deployment failures. It also accepts your own events, but mixing them with the AWS noise complicates the rules and the archive.
• Custom bus. The one your application creates for its business events. It allows its own access policies, its own archive and its own limits.
• Partner bus (partner event bus). Created by an associated SaaS to send you its events without you building webhooks: the payment gateway, the cloud ERP or the support tool.

MercadoFresco separates things clearly: bus-mercadofresco for the events the application publishes, and the default bus to react to what AWS does.

Every EventBridge event has the same envelope. The fields you control are four; the rest are set by the service.

Two warnings about detail. First: the whole event cannot exceed 256 KB, the same as an SQS message; if the detail is large, store it in S3 and send the reference. Second: detail is a contract with third parties, not an internal structure. We will come back to it at the end of the lesson.

Before writing a single rule, Marta and Luis write the catalogue. It is a one-page document, and it is the most profitable piece of governance in the whole module.

Three conventions that avoid a lot of pain. The detail-type is in the past tense and describes a fact, not an order: PedidoConfirmado, not ConfirmarPedido; if it describes an order, you are back to the coupling you wanted to avoid. The source identifies the emitting domain, not the team or the technical service, so that it survives reorganisations. And the detail always carries version, which is the only thing that will let the contract evolve without breaking consumers.

Publishing is a single call:

put_events accepts up to 10 entries per call and has the same trap as send_message_batch from 07-01: 200 with partial failures inside. If you do not check FailedEntryCount, you lose events silently.

A rule has a pattern and up to five targets. An event pattern is a JSON with the same shape as the event, where each value is a list of alternatives. The event matches if every field in the pattern coincides.

The simplest pattern: all confirmed orders.

From there the language grows. These are the operators, applied to the order's detail:

The composition rules are the same as in SNS and they are still the number one source of patterns that do not match: within a field the list is an OR; between different fields it is an AND. This pattern demands both things at once:

And this one selects urgent or large, which is different:

Arrays have a semantics of their own that has to be understood. The pattern {"detail":{"lineas":{"sku":[{"prefix":"PESC-"}]}}} matches if any of the lines starts with PESC-. There is no way to require that all of them do: EventBridge evaluates arrays with existential semantics. If you need "all", the filter goes in the target, not in the rule.

Creating the rule and attaching targets to it:

Testing a pattern without publishing anything is possible and always worth doing:

A rule accepts up to five targets, of more than 20 types. The ones MercadoFresco uses:

The API destination deserves attention because it solves a real problem. Calling an external API from a Lambda forces you to manage credentials, retries and rate limits by hand. With an API destination EventBridge does it: it keeps the credentials in a connection (which in turn deposits them in Secrets Manager), adds the authentication header, and limits the invocations per second.

--invocation-rate-limit-per-second 12 is exactly the limit the ERP can take. EventBridge does not exceed it even if 900 events arrive at once, and the rest wait with retries.

Input transformation (input transformer) avoids the coupling between the event format and what the target expects. Without it, the ERP would have to understand EventBridge's full envelope and the exact name of our fields, and any change in the event would break the partner.

InputPathsMap extracts values with JSONPath and gives them an alias; InputTemplate composes the payload the target receives. The result is that the ERP receives its own vocabulary (orderRef, customerRef) without MercadoFresco having to rename anything in its event. The translation lives in the rule, which is the cheap place to change it.

If a target fails, EventBridge retries with exponential backoff for 24 hours and up to 185 attempts by default. Both limits are adjusted per target, and the first one to be reached stops the attempts:

• MaximumRetryAttempts: maximum number of retries (0–185).
• MaximumEventAgeInSeconds: maximum age of the event (60–86,400 s).

MaximumEventAgeInSeconds is the parameter that is forgotten most and the one that matters most for the business. A delivery notice arriving 20 hours late is worth nothing: it is preferable for it to fall into the DLQ within the hour and for somebody to look at it, rather than arriving when the delivery has already happened. Marta sets it to 3,600 s for everything related to orders.

The DLQ per target (DeadLetterConfig) collects what could not be delivered. It is an ordinary SQS queue, and the message that arrives includes attributes with the reason: RULE_ARN, TARGET_ARN, ERROR_CODE, ERROR_MESSAGE and EXHAUSTED_RETRY_CONDITION. That last field is pure gold for diagnosis: it says whether the retries were exhausted or the maximum age expired.

Do not confuse the three DLQs that now coexist in MercadoFresco:

This is the capability SNS does not have: more than 200 AWS services publish to the default bus without you configuring anything. All you have to do is write the rule.

An instance from the shop's group shutting down or moving to a degraded state:

A Trusted Advisor finding (05-05), which until now had to be checked by hand:

An ECS task that dies (module 10) or a CodeDeploy deployment that fails (08-03):

Beware of that last one: when combining two sources in one rule, the detail pattern applies to both and may match neither. One rule per source is cleaner, even if it looks repetitive: the patterns stay readable and each one can have its own targets and its own DLQ.

MercadoFresco creates regla-mf-infra-incidentes with alertas-mercadofresco as its target, and the input transformation turns the raw event into a sentence Marta can read:

This is a good moment to point out the change of mindset: operations moves from checking to reacting. Instead of somebody reviewing Trusted Advisor every Monday, an event opens a ticket when there is something to look at.

EventBridge also fires on time. There are two mechanisms and it is worth knowing which to use.

The classic scheduled rules live on the default bus and use schedule-expression:

EventBridge Scheduler is the dedicated service, newer and preferable for almost everything: it supports time zones with daylight saving, dispersion windows (flexible time windows) so as not to launch a thousand tasks in the same second, one-off schedules, and more than 270 targets with the same retries and DLQ as the rules.

The --schedule-expression-timezone "Europe/Madrid" is the main reason to prefer Scheduler: with a classic rule in UTC, the nightly load would run at 04:30 in winter and 03:30 in summer, out of line with the accounting close. And MaximumWindowInMinutes: 15 spreads the start so as not to create a peak of connections against aurora-mf-lector-2.

MercadoFresco's two nightly tasks end up like this: programador-mf-carga-nocturna at 02:30 mainland time loads the day's orders into analitica.hechos_pedidos in wg-mercadofresco-analitica, and programador-mf-limpiar-carritos at 03:00 walks through and consolidates what the TTL of mercadofresco-carritos has already been expiring. Careful: AWS cron expressions have six fields (minute, hour, day of month, month, day of week, year) and do not accept * in day of month and day of week at the same time —hence the ?—.

The schema registry stores the structure of your events in OpenAPI/JSON Schema format. With discovery enabled on a bus, EventBridge infers the schema of what passes through it and versions it automatically.

From a schema you generate code bindings for Python, Java or TypeScript: typed classes that represent the event, so the consumer stops writing event["detail"]["pedido_id"] with its fingers crossed. In Python the added value is smaller than in Java, but the registry is still useful for another reason: it is the living documentation of the catalogue. When marketing asks what fields PedidoConfirmado carries, the answer is a versioned schema, not a chat message. Discovery costs about 0.10 USD per million events processed, so it is worth keeping it on only while the catalogue is evolving.

This is the capability that would have saved the 07-02 incident. An archive keeps a copy of every event that passes through a bus —optionally filtered by pattern— for as long as you decide.

And when something goes wrong, a time window is replayed towards the affected rules:

FilterArns is essential and it is what separates a recovery from a disaster: without it, the replay fires every rule on the bus, and you would charge cards again, send emails again and tell the warehouse about orders from six hours ago. With it, only the analytics rule is reprocessed, which is the one that missed the events.

Three more things to know before using it in earnest:

• Replayed events carry replay-name in the envelope. A consumer can tell them apart and act accordingly —for instance, not notifying anybody again—.
• Ordering is not guaranteed within the replay, and the events arrive far faster than they did originally. The consumer must be idempotent and keep up with the pace.
• Replaying costs the same as publishing. A month of events replayed is a month of events billed again, plus the archive storage (about 0.10 USD per GB per month).

The archive is also useful for something less dramatic and very handy: populating a test environment with real traffic, replaying a Friday afternoon against a development bus.

In 06-02 we enabled DynamoDB Streams on mercadofresco-carritos and left it there, introduced and unexploited. EventBridge Pipes is the missing piece: a point-to-point pipeline between a source that is polled and a target, with two optional steps in between.

The Pipes sources are the ones that have to be polled: DynamoDB Streams, Kinesis, SQS, Amazon MQ and Kafka. The targets are any of EventBridge's. And the two intermediate steps are the reason it exists:

• Filtering: discards what is not of interest before paying to process it. The basket stream generates one record per UpdateItem —hundreds of thousands a day— but the only ones of interest are the REMOVEs caused by the TTL, which are the genuinely abandoned baskets.
• Enrichment: calls a Lambda, an API or a state machine to complete the record before delivering it. The stream carries the CLIENTE#<id> but not the email or the name; the enrichment looks them up in Aurora.

The filter has an exquisite detail: userIdentity.principalId = dynamodb.amazonaws.com distinguishes the deletions made by the TTL from those the application makes when confirming an order. Without that condition, marketing would send "you forgot something" emails to customers who have just bought. It is a perfect example of why filtering has to sit close to the source and understand the domain.

This closes a thread that had been open since module 6: the 55 GB of zombie baskets that the TTL started cleaning up now also generate a business event you can use.

Events decouple, but not for free. There are three truths worth accepting early.

An event is a public API. As soon as you publish it on a shared bus, you do not know who consumes it: that is the point. And then you cannot change it as you please. Removing a field, renaming it or changing its type breaks consumers you do not even know exist, and you find out in production.

The rules of compatible evolution are short: you can add optional fields; you cannot remove or rename a field, change its type, change the meaning of an existing value, or tighten a constraint. When an incompatible change is needed, a new version is published in parallel —"version": 2 in the detail, or a new detail-type PedidoConfirmadoV2— and both are kept until the consumers migrate. That is why version goes in the detail from the very first event: without it, the migration has nowhere to start.

Coupling does not disappear, it moves. Before, the shop depended on the ERP; now everybody depends on the event format. It is a very favourable change —the contract is explicit, versionable and verifiable with test-event-pattern— but it is still a dependency. The discipline that keeps it healthy is the catalogue's: nothing is published on bus-mercadofresco without being in the table, and nothing is changed without bumping the version.

One last warning about design: events describe facts, commands order actions. If your event is called EnviarCorreoConfirmacion, you have put an order on a bus, and the sender knows again what has to happen next. The correct event is PedidoConfirmado; that this implies an email is the consumer's decision.

The most useful combination for debugging is MatchedEvents = 0 with non-zero publications: it means no pattern matches, and it is almost always a misspelt source or a detail-type with one capital letter of difference —patterns are case-sensitive—.

EventBridge also integrates with CloudWatch Logs as a target: a rule with a broad pattern and a log group as its target lets you see everything that goes through the bus during an investigation. It is expensive to leave on permanently, but it is the quickest tool when something does not turn up.

Unfiltered events are what can blow up the bill: if the basket pipe did not filter out the MODIFYs, it would process 5.4 million records a month instead of 210,000. Filtering at the source is not just design hygiene; it is the main line item.

A bus cannot be deleted if it has rules with targets: you have to remove targets, then rules, then the bus. It is the usual cause of ResourceInUseException in cleanup scripts.

A pattern that does not match because of capitals or a misspelt source. MatchedEvents at 0 with no error at all. Use test-event-pattern before deploying; it saves you hours. And do not confuse OR and AND: within a field, list = OR; between fields, AND; for an OR between fields, $or.

Expecting a pattern over an array to require "all". EventBridge evaluates arrays with existential semantics: it matches if any of the elements complies.

Not checking FailedEntryCount in put_events. It returns 200 with partial failures, just like send_message_batch. Events lost silently.

Publishing business events on the default bus. They get mixed with the AWS noise, the rules become fragile and the archive fills with events nobody wants. Use a bus of your own.

Leaving the maximum event age at 24 hours. A delivery notice arriving 20 hours late is worse than a visible failure. Set MaximumEventAgeInSeconds to the business value.

Replaying without FilterArns. It fires every rule on the bus and repeats effects that already happened. It is the most expensive mistake in this lesson.

Forgetting the target's DLQ. Without it, what is not delivered disappears without a trace.

Putting commands on the bus. If the detail-type is a verb in the imperative, you have reintroduced the coupling you wanted to eliminate.

Changing the detail without bumping version. You break consumers you do not know exist and you find out in production.

Tip: one rule per intention, not one rule with five heterogeneous targets. Separate rules have their own DLQ, their own maximum age and their own metric, and they can be disabled one at a time during an incident.

Tip: write the catalogue before the code. The table of source / detail-type / fields is ten minutes of work that prevents months of incoherent events.

Tip: enable the archive from day one. It costs pennies and it is the only way to recover what a misconfigured consumer missed.

Design the rules for bus-mercadofresco for these four requirements: (1) every PedidoConfirmado goes to cola-mercadofresco-almacen; (2) PedidoConfirmado events in the 24h slot or with an amount ≥ 100 € also go to the ERP's API destination with priority; (3) StockBajo events for fresh products (SKUs starting with FRUT- or PESC-) with fewer than 5 units notify alertas-mercadofresco; (4) any event from mercadofresco.* is archived for 90 days.

Write the JSON patterns, say how many rules you create and why, and what input transformation you would use in requirement 3.

On Tuesday at 09:00 Luis deploys a version of the analytics Lambda that throws an exception on start-up. Nobody notices until 15:00. The rule regla-mf-pedido-confirmado-analitica delivers directly to that Lambda, with no queue. The archive has been active for three months.

Answer: (a) what has happened to the events of those six hours according to the default retry configuration and according to a maximum age of 3,600 s; (b) how you recover the data, with the exact command; (c) what precaution you take before launching it; (d) which two architectural changes stop it happening again; (e) what alarm would have warned at 09:05.

Decide the service and justify it in two sentences: (a) three teams want the confirmed orders, with simple filters and the lowest possible latency; (b) the partner's ERP has to be called over HTTPS with an API key and at most 12 requests per second; (c) the on-call engineer has to be warned by SMS; (d) the Redshift load has to be launched every day at 02:30 mainland time; (e) you have to react to the TTL deletions in mercadofresco-carritos enriching them with data from Aurora; (f) you have to react to an EC2 instance moving to terminated.

Solution 1

Four rules plus an archive. They are kept separate because each one has its own target, maximum age and DLQ, and because a rule with mixed patterns becomes unreadable.

(1) regla-mf-pedido-confirmado-almacen:

(2) regla-mf-pedido-prioritario-erp. The OR between different fields forces $or:

Target destino-api-erp-almacen with a low MaximumEventAgeInSeconds (900 s: an urgent order that does not arrive within 15 minutes has to be handled by hand) and DLQ mercadofresco-eventbridge-fallidas.

(3) regla-mf-stock-bajo-fresco. Here it is an AND between fields: SKU prefix and units.

The two prefix entries inside the sku list are an OR, which is exactly what is asked for. Input transformation, because the target is an SNS topic that ends up in a person's email:

(4) It is not a rule, it is an archive with the pattern {"source":[{"prefix":"mercadofresco."}]} and --retention-days 90. The prefix avoids archiving AWS events that add nothing and do take space.

Solution 2

(a) With the default values (185 retries, 24 hours), the 09:00 events would still be retrying at 15:00, and once the Lambda was fixed some of them would be delivered on their own, though hours late and out of order. With MaximumEventAgeInSeconds=3600, each event is discarded an hour after it was published: at 15:00 everything before 14:00 is in the target's DLQ and the rest is still retrying. The second configuration is preferable: it turns a silent degradation into a visible pile of messages in the DLQ.

(b) First you fix the Lambda and check it with a test event. Then:

The times go in UTC: 09:00–15:00 mainland time in August is 07:00–13:00 UTC. Getting this wrong is a classic.

(c) Three precautions. FilterArns is mandatory, or the replay would fire every rule and would notify the warehouse again and bill orders from six hours ago all over again. Check that the consumer is idempotent, because some of the events may have been delivered before the failure and the replay will repeat them. And empty or review the target's DLQ first, to avoid double routes.

(d) First, put a queue between the rule and the Lambda: with SQS, six hours of failure leave 5,000 messages waiting and they are processed once the problem is fixed, with no replay at all; it is the same lesson from 07-02 applied to EventBridge. Second, a DLQ on the target plus an alarm, so the signal appears within minutes. As a third measure, a deployment with a health check that rolls back on its own, which is precisely the subject of module 8.

(e) An alarm on the rule's FailedInvocations, threshold > 0 over a 5-minute period, towards alertas-mercadofresco. A complementary one: the Lambda function's Errors. Either of the two would have warned at 09:05 instead of at 15:00.

Solution 3

(a) SNS. Pure fan-out, simple filters and a minimum-latency requirement: SNS delivers in tens of milliseconds against EventBridge's hundreds, and it is already built. Each team with its own queue.

(b) EventBridge with an API destination. It is exactly its use case: it manages the key in a connection backed by Secrets Manager, applies invocation-rate-limit-per-second 12 and retries with a DLQ, all without writing a line of code.

(c) SNS. It is the only one of the three that delivers SMS. On top of that, the CloudWatch alarm already publishes there natively.

(d) EventBridge Scheduler. It needs a time zone with daylight saving (Europe/Madrid), which classic scheduled rules do not support, and the flexible window avoids the peak of connections against the Aurora reader.

(e) EventBridge Pipes. It is the only one that consumes DynamoDB Streams with filtering before billing and with an integrated enrichment step. Doing it with a Lambda subscribed to the stream would force you to filter and enrich by hand, processing —and paying for— millions of unwanted MODIFYs.

(f) EventBridge, default bus. The EC2 events arrive on their own and are free; there is nothing to publish. A rule with a pattern over aws.ec2 and alertas-mercadofresco as its target.

MercadoFresco no longer has one topic per kind of fact, but one bus where PedidoConfirmado, PedidoCancelado, StockBajo and RepartoAsignado live together, and where rules with JSON patterns decide where each one goes by looking at its content: the slot, the amount, the province, the SKU prefix. The partner's ERP receives its own vocabulary thanks to the input transformation, without anybody renaming anything in the event. The nightly tasks —the load into analitica.hechos_pedidos and the basket consolidation— run with programador-mf-carga-nocturna in mainland time and with a flexible window. Infrastructure incidents and Trusted Advisor findings arrive on their own, without anybody having to go and look. And the mercadofresco-carritos Streams, introduced in 06-02 and unused until today, finally feed a business event through pipe-mf-carritos-abandonados, with a filter that tells the TTL deletion apart from the purchase deletion.

Two ideas carry the weight of the lesson. The first is that content-based routing changes who decides: it is no longer the sender that hands out work, but a declarative rule that is modified without deploying code. The second is that an event is a public API, with everything that implies: you can add, you cannot remove, and without version in the detail no migration is possible. In between sits archivo-mercadofresco-eventos, the safety net that turns "we have lost six hours of data" into a one-command replay —always with FilterArns, or the cure will be worse than the disease—.

But look at what is still unsolved. Everything we have built is choreography: each component reacts to what it sees and nobody has the full picture. It works beautifully for independent facts, and it breaks when the process has steps that depend on one another and you have to undo what has been done if something fails halfway. The MercadoFresco order is exactly that: charge, reserve stock, ask the warehouse to prepare it —which takes between two minutes and an hour and is confirmed by a person with a barcode scanner—, assign delivery and confirm to the customer. If the warehouse cannot prepare the box because the fish arrived in poor condition, the charge has to be refunded and the stock released, and with loose events nobody knows where the process was or what needs compensating.

In 07-04, "AWS Step Functions", we move from choreography to orchestration: a state machine, mercadofresco-procesar-pedido, that knows the whole process, records which step it is on, retries with exponential backoff, waits for a human to confirm through a task token, processes Friday's 900 confirmations in parallel with distributed Map, and —most importantly— knows how to undo what it had already done when something goes wrong.