Let us go back to the AlpinaShop application for a moment. A customer presses "Confirm order". The Flask function handling that request has to do several things: save the order in alpinashop-pedidos, take payment at the payment gateway, tell the warehouse to prepare it, tell billing to issue the invoice, send the confirmation email, decrement stock, and — since module 4 — inform analytics.

Today, that code is a list of calls, one after another. And that list has three problems that do not show up until the worst day of the year.

The customer waits for all of them. The purchase's response time is the sum of the seven steps. If the mail service takes four seconds, the customer watches a spinner for four extra seconds over something they do not care about: they have already bought.

One failure brings it all down. If the warehouse system is restarting, the call fails. And now what? Do you undo the order, which has already been charged? Do you carry on and lose the notification? Do you retry and run the risk of duplicating the invoice, which did go out? There is no good answer.

Every new addition touches the purchase code. Adding analytics means modifying, testing and deploying the shop's most critical function. And then the loyalty programme will arrive, and the fraud checks, and the supplier notification. The purchase function grows without pause and every change puts the till at risk.

Cloud Pub/Sub solves all three at once with a very simple idea: instead of calling seven systems, the shop publishes a fact — "order PED-2026-0042 has been confirmed" — and gets on with its business. Whoever is interested in that fact subscribes. The shop neither knows nor cares how many there are.

In this lesson you will create the pedidos-nuevos topic and its subscriptions, publish from Flask, consume in all four possible ways, understand the service's real guarantees — which are not the ones people assume — and learn why idempotency is not an architectural ornament but an unavoidable requirement.

1. The coupling problem, before and after
2. The publish-subscribe model
3. Pub/Sub's real guarantees
4. Creating the pedidos-nuevos topic and its subscriptions
5. Publishing from the Flask application
6. Pull consumption with the asynchronous client
7. Push consumption to an HTTPS endpoint with OIDC
8. Acknowledgements, deadlines and retries
9. Dead letter topics
10. Idempotency: the consumer must tolerate duplicates
11. Retention, seek and snapshots
12. Subscription filters by attribute
13. BigQuery and Cloud Storage subscriptions
14. Ordering by key and its implications
15. Pub/Sub Lite and other alternatives
16. Monitoring and cost
17. The alpinashop-catalogo bucket notifications

What changes concretely:

The technical expression of this is decoupling: the producer does not know the consumers, does not know how many there are, does not wait for their reply and does not fail if they fail. The price is that the system becomes eventually consistent: when the shop replies "order confirmed", the warehouse does not know yet. It will know in a few milliseconds, or in a few seconds if it was busy. That nuance has to be accepted consciously, because it changes how the screens are designed: you cannot show "preparing shipment" immediately after the purchase if the warehouse has not found out yet.

Four concepts, and it is worth being precise about them because the vocabulary is often misused.

Topic. The channel where things are published. It represents one type of fact: pedidos-nuevos, imagenes-subidas, stock-agotado. A topic stores nothing by itself; it is an entry point.

Subscription. The queue of one specific consumer over a topic. This is where the messages actually live. Each subscription receives an independent copy of every published message, and keeps its own accounting of what it has acknowledged and what it has not.

That last point is the key that is hardest to internalise:

The warehouse acknowledging has no effect whatsoever on analytics' copy. They are separate queues fed by the same topic.

And the practical corollary: if you connect two instances of your warehouse service to the same sub-almacen subscription, each message will go to one of the two. That is load sharing, and it is what you want in order to scale. If instead you create two different subscriptions for the same service, each instance will process every message and the work will be done twice. One subscription per logical consumer, as many instances inside as you like.

Message. It has three parts:

• data: the body, bytes (typically UTF-8 encoded JSON). Maximum 10 MB.
• attributes: text key-value pairs, up to 100. They are metadata, and their great virtue is that they can be filtered on without opening the body.
• System fields: messageId (unique, assigned by Pub/Sub), publishTime, optional orderingKey.

Acknowledgement (ack). The consumer says "processed, do not send it to me again". Until that acknowledgement arrives, Pub/Sub considers the message outstanding and will redeliver it.

This section is the most important in the lesson, because most production mistakes with messaging come from assuming guarantees that do not exist.

The first two rows deserve elaboration, because they are counter-intuitive.

Why there will be duplicates. The scenario is simple: your consumer receives the message, processes it correctly, sends the acknowledgement, and the acknowledgement is lost on the network. Pub/Sub does not receive it, considers the message still outstanding and redelivers it. Your consumer processes it a second time. There is no fault in your code and it has happened anyway.

It also happens if the consumer takes longer than the ack deadline, if it restarts mid-processing, or if autoscaling reassigns the message. It is normal, it is to be expected and it is not an error. That is why section 10 exists.

Exactly once. Pub/Sub offers subscriptions with this semantics (--enable-exactly-once-delivery), with two important caveats: it only applies within a region, and it guarantees that there will not be a second acknowledged delivery, not that your processing is atomic. If your consumer writes to the database and then crashes before acknowledging, the work is already done and the message will come back. Idempotency is still necessary; exactly once only reduces how often you need it.

Why there is no order. Pub/Sub spreads the messages across many servers in order to scale. If message A is published a millisecond before B, they can end up on different servers and arrive in any order. For AlpinaShop this matters little in pedidos-nuevos — each order is independent — but it would matter enormously if we published state changes for the same order: "confirmado", "enviado", "entregado" out of order would leave the order marked as confirmed after being delivered. That case is solved with an ordering key (section 14).

--message-retention-duration on the topic enables replay: it lets you seek to an instant in the past even for subscriptions created afterwards. Without it, you can only go back within whatever each subscription retains.

Now the dead letter topic, which we will create before the subscriptions because they are going to need it:

The three consumption subscriptions:

Notes on the differences, which are deliberate:

• sub-facturacion with exactly once. Issuing two invoices for the same order is a real accounting problem. Although the consumer must be idempotent anyway, this guarantee reduces the exposure. It has a cost: a lower maximum throughput per subscription.
• sub-analitica with no dead letter. The Dataflow pipeline already has its own quarantine mechanism (04-02): malformed messages go to pedidos_streaming_errores. Duplicating the mechanism would complicate diagnosis.
• Different ack deadline values. 30 s for the warehouse (a fast operation), 120 s for analytics (Dataflow processes in internal batches).

The dead letter needs explicit permissions, and this is always forgotten:

Without these two permissions, the dead letter configuration is accepted without complaint and does not work: the messages are retried forever instead of being diverted. It is a classic silent failure.

Verification:

Now Dani's part, the backend developer. Publishing from the catalogue application:

And how it is used in the Flask view:

Four design questions that deserve to be made explicit:

What goes inside the message. Here we publish a fat event, with the lines included. The alternative is a thin event with just the pedido_id, forcing every consumer to query the database. The fat one avoids that read load but couples the message schema; the thin one is more flexible but multiplies the queries against Cloud SQL. For AlpinaShop, with ~1,200 orders a month, the fat event is clearly better: fewer calls to the operational database and self-sufficient consumers.

version_esquema as an attribute. The day the message structure changes, old consumers will be able to recognise and reject what they do not understand instead of breaking. It costs one attribute and it saves an incident.

The momento_evento. It is the attribute the Dataflow pipeline from 04-02 uses as its timestamp_attribute. Without it, the event-time windows do not work.

What happens if the publication fails. It is the real risk of this design: the order is charged and the notification never went out. For AlpinaShop, logging with an alert is enough given the volume. In more demanding systems the outbox pattern is used: the event is written to a table in the same database within the order's own transaction, and a separate process publishes it. That way the event and the order are atomic.

A quick test from the command line:

In pull mode, the consumer asks for messages. The Python library uses streaming pull: it keeps a connection open and receives messages as they arrive, with very little latency.

Three points that make the difference between a toy consumer and a production one:

Flow control. Without FlowControl, the library accepts as many messages as it is sent. If your processing is slow, many will pass their deadline, be redelivered, be processed again by your consumer, and you will enter a spiral in which there is more and more duplicated work. Limiting the messages in flight is what avoids that spiral.

ack() versus nack(). ack() removes the message for good. nack() returns it for immediate redelivery. If you do neither, the message is redelivered when the deadline expires, which delays the retry but works just the same.

Telling recoverable errors from unrecoverable ones. A corrupt JSON will not improve by retrying it five times: it is discarded with a log entry. A saturated database will: nack(). Confusing them means either that poisoned messages consume resources indefinitely or that recoverable data is lost.

There is also synchronous pull, useful for batch processes:

In push mode, Pub/Sub makes an HTTPS POST to a URL of yours. You keep no process listening: the service calls you.

Push fits perfectly with what is coming in the course: Cloud Run (07-02, where the catalogue will end up according to decision DA-001) and Cloud Functions (06-03) scale to zero, so there is no sense in having a process sitting waiting for messages.

The secure configuration uses OIDC authentication: Pub/Sub attaches a token signed by Google identifying a service account, and your endpoint verifies it. Without this, anyone who discovered your URL could inject fake messages.

The receiving endpoint:

The golden rule of push: the HTTP response code is the acknowledgement. 2xx removes the message; anything else (or a timeout) puts it back in the queue. Returning 200 from a generic except "so it stops bothering us" is the fastest way to lose data silently.

The ack deadline is how long Pub/Sub waits for the acknowledgement before redelivering. 10 seconds by default; configurable between 10 and 600.

If the consumer neither acknowledges nor extends the deadline, the message goes back into the queue. Choosing the deadline well matters:

• Too short: messages that are being processed correctly get redelivered and the work is duplicated.
• Too long: if a consumer dies, its messages take a long time to be reassigned to another.

Rule of thumb: the 99th percentile of your processing time, with margin. If 99 % of picking orders are created in under 8 seconds, 30 seconds is reasonable.

The good news is that the Python library extends the deadline automatically while your callback is still running (lease management), up to a configurable maximum. If you need to extend it by hand:

The retries follow the policy you configured:

With exponential backoff, the retries are spaced out: 10 s, 20 s, 40 s, 80 s… up to 600 s. This is the right thing when the failure is because a system is saturated: retrying every second would sink it further. Without backoff, a consumer that is down generates a storm of retries that prevents it from recovering.

Imagine a message with a sku that does not exist in the catalogue. The warehouse consumer fails. It retries. It fails. It retries. Forever. That message is called poisoned, and without a dead letter it has three consequences: it consumes resources indefinitely, it clutters the logs, and — if ordering is enabled — it blocks every subsequent message with its key.

The dead letter topic solves this: after N attempts, the message is diverted to another topic and removed from the original subscription.

When a message reaches the dead letter, it keeps its body and its attributes and gains metadata about the origin and the number of attempts. A review process, typically weekly:

Dead letter rules worth fixing as team policy:

1. Every production subscription has one. No exceptions. It is the difference between "something failed and we have it saved" and "something failed and we do not know what it was".
2. max-delivery-attempts between 5 and 10. Fewer, and a transient failure sends good messages to the dead letter queue. More, and it takes too long to spot the problem.
3. An alert on the number of messages in the dead letter. A dead letter nobody looks at is a black hole with extra steps.
4. Do not point a dead letter at the original topic. That is an infinite loop, and it is a mistake made more often than you would think.

We already know there will be duplicates. The solution is not to avoid them — you cannot — but to make processing the same message twice have the same effect as processing it once. That is idempotency.

Three strategies, from least to most robust.

The best one, when it is possible: design the operation so that repeating it changes nothing.

Use a uniqueness constraint in the database:

This is the preferable option when a natural business key exists, as pedido_id does here. Zero added infrastructure and the database provides the guarantee.

When the operation is neither idempotent nor has a natural key (sending an email, calling an external API), you have to keep a register. Firestore, which AlpinaShop already uses for the shopping cart (02-06), is ideal thanks to its low latency and its transactions:

And how it is used:

The comment about the key is the most important part of this whole section. Using message_id protects against Pub/Sub redeliveries, but not against a reprocessing run with seek nor against a republication from the application. Using the business identifier (pedido_id) protects against both. It is the difference between a system that survives a reprocessing run and one that invoices twice the day somebody replays an hour of messages.

A practical detail: the register's TTL must be longer than the subscription's maximum retention. If Pub/Sub can redeliver for 7 days and your register expires after 3, a message redelivered on day 5 would be processed again.

Messages are retained in the subscription for between 10 minutes and 31 days (7 by default). With seek you move the read point.

Real cases where seek saves the day:

• A bug in the analytics consumer computed VAT wrongly for six hours. You fix the code, deploy, seek back six hours and reprocess everything. With idempotent consumers this is safe. Without idempotency it is a disaster.
• A queue accumulated 400,000 obsolete messages because of a consumer that was down over the weekend. seek to the present discards them in one go.

Snapshots capture a subscription's acknowledgement state so you can return to it:

It is the equivalent of a restore point before a risky deployment, and it should be part of the deployment procedure for any consumer that writes to business systems.

A subscription can filter on the message attributes, so that it only receives what interests it. The filtering happens on Pub/Sub's side: discarded messages are neither delivered nor billed as a delivery.

Available operators: =, !=, AND, OR, NOT, hasPrefix(), and attributes:key to check for existence.

Two limitations you have to know about:

• You can only filter on attributes, never on the body. If you want to filter on the amount, you have to publish it as an attribute. That is why the publisher in section 5 includes pais and origen as attributes even though they are also inside the JSON.
• The filter is immutable. It cannot be modified once the subscription is created; you have to create another one.

Filters allow a very clean pattern: one topic per domain, with many event types, and each consumer filtering out its own. For AlpinaShop, one eventos-tienda topic with pedido_confirmado, pedido_cancelado, carrito_abandonado and stock_bajo is more manageable than four topics, because it preserves the relative order of events from the same domain and simplifies the publisher.

Here comes one of the service's best features, and the one that saves the most code.

A BigQuery subscription writes the messages straight into a table. No Dataflow, no code, nothing to deploy.

• --use-table-schema: JSON is expected whose fields match the columns. The alternative, --use-topic-schema, validates against an Avro or Protobuf schema registered on the topic.
• --drop-unknown-fields: JSON fields that do not exist as a column are ignored instead of causing a failure. Essential if the message schema can evolve.
• The dead letter here is fundamental: without it, a message that does not fit the schema is retried indefinitely.

The honest comparison:

AlpinaShop's decision: to dump the raw events into a landing table, a BigQuery subscription, because it is free in effort and there is nothing to maintain. The Dataflow pipeline is reserved for what genuinely needs transformation: the aggregate per hour and channel with event-time windows and tolerance for late data. It is the usual and correct pattern: raw data by the cheap route, aggregates by the powerful route.

The Cloud Storage subscription does the equivalent with files, batching messages by time or size:

It is an excellent way to keep an immutable archive of every event in the lake, later processed by Spark (04-03) or loaded into BigQuery. And it is the ultimate safety net: if one day the whole analytical warehouse has to be rebuilt, the raw events are there.

By default there is no order. To guarantee it, you publish with an ordering key:

The guarantee is: messages with the same ordering key, published in the same region, are delivered in publication order. Messages with different keys have no relationship with each other, which allows parallelism to continue.

The three costs of enabling ordering, which have to be weighed up:

1. Lower throughput. The messages for one key are processed sequentially. With pedido_id as the key there is no problem: there are thousands of distinct orders and parallelism is preserved. With pais as the key, every order from Spain would go in series.
2. Blocking on a poisoned message. If a message with key PED-2026-0042 fails repeatedly, every subsequent message for that order is blocked until it is resolved or diverted to the dead letter. Ordering without a dead letter is a time bomb.
3. Slower publication. The client has to serialise each key's sends, which reduces the effect of batching.

Golden rule: enable ordering only when the order is semantically necessary, and choose the key with the highest possible cardinality that preserves that order. For AlpinaShop: pedido_id yes (an order's states must go in order); pais no.

And the alternative that is usually better: make the order irrelevant. If each event includes a version number or a timestamp, the consumer can discard those that are older than what it has already processed, and arrival order stops being a problem.

Pub/Sub Lite was a lower-cost variant, with capacity provisioned by the user rather than served on demand, intended for very high and predictable volumes. It required sizing partitions and storage by hand, in exchange for a considerably lower price per GB.

Google announced its retirement and the service stopped being available in March 2026. If you find references to Pub/Sub Lite in old documentation or courses, they are obsolete; always verify the status in the official documentation. The current alternatives are standard Pub/Sub or, if you need the Kafka API, Google Cloud Managed Service for Apache Kafka.

The comparison that is still useful:

The most common confusion is Pub/Sub versus Cloud Tasks. Pub/Sub is for facts that interest N unknown consumers. Cloud Tasks is for assignments addressed to a specific recipient, with fine control of the delivery rate and deferred scheduling. "An order has been confirmed" is Pub/Sub. "Send this email in 30 minutes, at a maximum of 10 per second" is Cloud Tasks.

The metrics to watch, with their alerts:

The essential alert:

oldest_unacked_message_age is the best metric because it detects all three possible failures at once: a consumer that is down (it grows indefinitely), a slow consumer (it grows slowly) and a poisoned message blocking an ordered key (it sticks at a high value).

The cost is billed mainly by data volume:

A realistic calculation for AlpinaShop: 1,200 orders a month, messages of ~2 KB, with 4 subscriptions. That is 1,200 publications and 4,800 deliveries: around 12 MB a month. Cents, or simply within the free tier. The catalogue browsing events, far more numerous, would still be cheap.

One billing detail that surprises people: each subscription counts as a delivery. Ten subscriptions on the same topic multiply the billed delivery volume by ten. That is not a reason to avoid subscriptions, but it is a reason not to leave orphan subscriptions lying around: a forgotten subscription with no consumer piles up messages, its storage is billed and it serves no purpose.

Back in 02-02 a promise was left outstanding: that Cloud Storage can give notice when a new object appears. Now we have the pieces to keep it properly.

AlpinaShop's case: when someone uploads a product's original image to productos/<sku>/original/, the web/ and thumb/ versions have to be generated automatically. Today Marta does that by hand with a script.

Available event types:

The consumer:

The infinite loop filter deserves emphasis: it is the most expensive failure in this pattern. Writing to the same bucket that fires the notification creates a recursion that is only detected when the invoice arrives. The three defences are: filtering by prefix on the notification (--object-prefix=productos/), checking the path in the consumer, and — better still — writing the output to a different bucket from the input one.

This same pattern applies to the carrier's monthly file and to the nightly exports: as soon as the file lands in exportaciones/<yyyy>/<mm>/<dd>/, a notification triggers the load into BigQuery. No cron, no checking folders every five minutes, no waiting windows. We will put the processing logic in Cloud Functions in 06-03, and who orchestrates it all is the next lesson.

Assuming there will be no duplicates. There will be, with or without exactly once. Every production consumer must be idempotent. It is not optional.

Using message_id as the idempotency key. It protects against redeliveries, but not against seek or republications. Use the business identifier.

Configuring a dead letter and forgetting the permissions. The command is accepted and the feature does not work: messages are retried forever. Always check both bindings.

Not putting flow control in the consumer. With slow processing, the library accepts more messages than it can acknowledge, the deadlines expire, they are redelivered, and the consumer sinks processing duplicates of its own backlog.

Creating the Pub/Sub client inside the request handler. It is expensive (it opens gRPC connections). One per process, reused.

Returning 200 from a generic except in push. It acknowledges the message and loses it silently. Return 5xx on transient failures.

Enabling ordering without needing it. It reduces throughput and, with a poisoned message, blocks the whole key.

Pointing the dead letter at the original topic. Infinite loop.

Orphan subscriptions. With no consumer, they pile up messages until the maximum retention, their storage is billed and they contribute nothing. Review them periodically.

Bucket notifications that feed themselves. Writing to the same bucket that fires the event. Use separate buckets or prefixes and filter in the consumer.

Tip: publish attributes generously. They cost little and they allow server-side filtering, which saves deliveries and complexity in the consumer.

Tip: a schema on the topic. Pub/Sub can register an Avro or Protobuf schema and validate messages at publication time. It turns format errors into immediate publisher failures rather than surprises in the consumer.

Tip: take a snapshot before every risky deployment. It costs one command and it gives you a way back.

Create the opiniones-nuevas topic with 7 days of retention, its dead letter topic opiniones-nuevas-fallidos with an inspection subscription, and three subscriptions over the main topic:

• sub-moderacion: receives only the reviews with attributes.puntuacion_baja = "true", with a 60 s deadline, dead letter after 5 attempts and backoff from 10 s to 300 s.
• sub-analitica-opiniones: receives them all, with a 120 s deadline.
• sub-bq-opiniones: writes straight into BigQuery in the table alpinashop-datos:alpinashop_analitica.opiniones, with no code.

Include every necessary permission and publish two test messages, one that reaches moderation and one that does not.

Write the pull consumer for sub-facturacion that issues each order's invoice. Requirements: flow control of 20 messages in flight; distinguishing transient errors (retry) from permanent ones (discard with a log entry); idempotency based on the business identifier with a register in Firestore and a suitable TTL; clean shutdown on SIGTERM; and a counter of invoices issued and duplicates detected. Explain why the idempotency key must be the pedido_id and not the message_id, with a concrete scenario in which the wrong choice would cause a real problem.

At 09:15 the alert fires: oldest_unacked_message_age on sub-almacen has been at 47 minutes and rising. num_undelivered_messages has gone from 3 to 12,400 since 08:20. The warehouse service is up and answers its health check. In the consumer's logs the same error message appears about a hundred times a minute, mentioning order PED-2026-1188. The pedidos-nuevos-fallidos queue is empty. The subscription has ordering enabled by pedido_id.

Diagnose what is happening, explain why the dead letter is empty despite the retries, and give an action plan in three phases: immediate containment, correction and prevention.

Solution 1

The point being assessed here is the filter: sub-moderacion receives one of the two publications, because the filtering happens on Pub/Sub's side and the five-star review is neither delivered nor billed.

Solution 2

Why pedido_id and not message_id, with a concrete scenario:

message_id is unique per publication. If the same business fact is published twice, each publication will have a different message_id, and a register based on it would detect nothing.

The real scenario: on a Tuesday, a bug in the billing consumer meant that 300 of the morning's orders were not invoiced. The code is fixed, deployed, and this is run:

That seek redelivers the morning's messages. Now, between 08:00 and the incident there were 500 orders, of which 200 were invoiced correctly before the failure began.

• With message_id as the key: redelivery preserves the original message_id, so in this specific case the 200 good ones would indeed be detected. But if instead of seek somebody recovers and republishes the events from the Cloud Storage archive (section 13), the message_id values will be new and 200 duplicate invoices would be issued. That is the failure.
• With pedido_id as the key: it does not matter how the message arrives — redelivery, seek, republication from the archive, manual reprocessing. If that order has already been invoiced, it is not invoiced again. The protection is over the business fact, which is what actually matters.

Two hundred duplicate invoices sent to customers is an incident for accounting, for customer service and for reputation. The difference between the two options is one line of code.

Solution 3

Diagnosis: a poisoned message blocking an ordering key, with the dead letter misconfigured.

The clues fit one by one:

1. The service is alive and responding. It is not an outage: it is a logical jam.
2. The same error a hundred times a minute about PED-2026-1188. That message always fails. It is a poisoned message: something in it (a non-existent SKU, a null field, an impossible amount) makes the consumer fail deterministically.
3. Ordering is enabled by pedido_id. Here is the critical part that explains the scale: with ordering, messages with the same key are delivered in order and a blocked one prevents progress. But on top of that, in practice, the combination of a consumer that nack()s in a loop over one key and flow control saturated by redeliveries makes overall throughput collapse: the consumer spends its capacity reprocessing the same message over and over instead of attending to the queue.
4. 12,400 messages piled up in 55 minutes when AlpinaShop takes ~1,200 orders a month: that volume is not new orders, it is redeliveries of the same message plus the rest of the queue going unattended.

Why the dead letter is empty. This is the part that teaches the most. There are two possible causes and both are common:

• The permissions are missing. The dead letter policy is configured without error even though Pub/Sub's service agent has neither roles/pubsub.publisher on the dead letter topic nor roles/pubsub.subscriber on the source subscription. Without those two permissions, the diversion never happens and the message is retried indefinitely. It is exactly the silent failure we warned about in section 4.
• The policy is not actually applied. The subscription was created without --dead-letter-topic and it was taken for granted.

Check:

Three-phase action plan:

Phase 1 — Containment (minutes). Fix the dead letter permissions, which is what unblocks things without losing anything:

As soon as the diversion works, PED-2026-1188 will leave the queue after five attempts and the rest of the messages will start to flow. Do not seek to the present: that would discard 12,400 messages, most of which are real orders waiting to be prepared.

If the diversion were slow and there were operational urgency, the alternative patch is to deploy a temporary rule in the consumer that explicitly acknowledges the problematic pedido_id, logging it so it can be handled by hand.

Phase 2 — Correction (hours). Inspect the message in the dead letter queue, understand why the consumer fails on it, and fix the code so that this kind of data is treated as a permanent error (ack() with a log entry) instead of being retried. Then handle order PED-2026-1188 manually, since it is still a real order from a real customer and it has to be prepared. Verify that the queue returns to an oldest_unacked_message_age measured in seconds.

Phase 3 — Prevention (days).

• Verify the dead letter on every subscription, including the permissions, not just the policy. Automate it as a check at deployment time.
• An alert on dead_letter_message_count > 0, so you find out about the first poisoned message instead of number 12,400.
• Review whether ordering is really necessary on sub-almacen. Orders are independent of each other; the order between different orders adds nothing and does add a blocking risk. If all that is needed is to order the state changes of a single order, that case can be solved with a version number and an UPDATE ... WHERE version < %s, removing ordering entirely.
• Classify errors in the consumer: transient → nack(), permanent → ack() with a log entry. The absence of that distinction is the root cause of one bad record bringing down a queue.
• Add the oldest_unacked_message_age alert at 10 minutes, not at 47.

AlpinaShop is no longer a monolith that phones everybody. In this lesson you have seen the coupling problem with concrete numbers — a purchase that waits 5.4 seconds for four systems the customer does not care about — and how it dissolves by publishing a fact instead of giving orders.

You have internalised the model: the topic is the type of fact, the subscription is where the messages actually live and each one receives its own independent copy, the message carries a body and filterable attributes, and the acknowledgement is the only thing that removes a message from the system. And above all you have seen the real guarantees, which are the ones that matter: at-least-once delivery, with duplicates that will happen even if your code is perfect; no order except with an ordering key; and exactly once as a reduction of the problem, not as its disappearance.

You have created pedidos-nuevos with 7 days of retention, the dead letter topic pedidos-nuevos-fallidos with its inspection subscription, and the sub-almacen, sub-facturacion — with exactly once, because duplicating an invoice is serious — and sub-analitica subscriptions, each with its deadline, its retry policy and its dead letter permissions, including the two bindings everybody forgets and without which the diversion silently fails to work.

You have published from Flask with batched sending, exponential backoff and a reused client, consciously deciding to publish a fat event with the lines inside and marking version_esquema and momento_evento as attributes. You have consumed in pull with flow control, clean shutdown and a distinction between transient and permanent errors; and in push towards an HTTPS endpoint with OIDC authentication, knowing that there the HTTP response code is the acknowledgement. You know the ack deadline, modifyAckDeadline and why the deadline is set to the 99th percentile of your processing.

You have understood why every serious consumer needs a dead letter — the poisoned message retried forever — and why the idempotency key must be the business identifier and not the message_id: a seek or a republication from the archive would issue duplicate invoices with the wrong choice. You have seen seek and snapshots as a safety net for reprocessing runs and risky deployments, the attribute filters that discard on the server side, and the BigQuery and Cloud Storage subscriptions, which ingest without a single line of code and which for AlpinaShop take the raw data while Dataflow keeps what genuinely needs transformation and windows.

You know when to enable ordering and at what price, that Pub/Sub Lite no longer exists and what to use instead, which metric to watch above all others — oldest_unacked_message_age — and that the cost, at AlpinaShop's volume, is cents. And you have finally kept the promise from 02-02: the alpinashop-catalogo bucket now gives notice when a new image appears, with the prefix filter, the path check and the idempotency by object generation that prevent the infinite loop that ruins the unwary.

Look at the map we now have. BigQuery stores and answers. Dataflow transforms in batch and in streaming. Dataproc computes the algorithmic things. Pub/Sub connects the systems without them knowing each other. That is a lot of machinery. And yet, there are two obvious gaps.

The first: the data that is not born in Google Cloud. AlpinaShop's warehouse ERP is a MySQL running on a server in the Sabadell offices. The carrier sends a monthly CSV by email. The backpack supplier offers a REST API with its catalogue. None of that publishes to Pub/Sub or writes Parquet into a bucket, and Lucía, who knows SQL but has never written Beam in her life, cannot depend on Dani for every new file.

In 04-05, Cloud Data Fusion, we will look at the tool designed for exactly that: visual, no-code data integration, with connectors for almost any source, an interactive cleaner called Wrangler where dates and nulls are fixed while you look at the data, field-level lineage that answers "where does this column come from?", and replication with change capture from that MySQL in Sabadell. And we will also look at its uncomfortable side — it charges per instance-hour and that shapes how it is used — with an honest table of when Data Fusion, when Dataflow, when Datastream and when a simple bq load will do.