In 05-05 an explicit loose end was left. AlpinaShop designed an event-driven architecture to process automatically every product image uploaded to the alpinashop-catalogo bucket: a message to the imagenes-subidas topic, a call to the Vision API, the labels written to alpinashop_analitica and a thumbnail generated. The design was clear. The implementation was postponed because one piece was missing: something that runs code when an event happens, without a server sitting there waiting.

That piece is Cloud Functions, and it is what we are going to build here from start to finish.

But first it is worth understanding why the problem is not trivial. The "obvious" solution would be to add an endpoint to the Flask catalogue that receives the notification and processes the image. It is a bad idea for three reasons: processing an image takes seconds and would block a gunicorn worker that should be serving customer requests; the catalogue would scale according to the image load instead of the web traffic; and a processing failure would affect the shop. Reacting to events wants its own life cycle, and that is exactly the gap FaaS fills.

1. What FaaS is and what the deployment unit is
2. Cloud Functions today: the 2nd generation on top of Cloud Run and Eventarc
3. HTTP functions: your first function and its deployment
4. Authentication: why they should almost never be public
5. Event-driven functions: CloudEvents and Eventarc
6. The pending case: procesar-imagen-producto from start to finish
7. Idempotency, retries and dead letter
8. The real life cycle: cold starts and concurrency
9. Configuration, secrets and identity
10. Connecting to the VPC to reach Cloud SQL
11. Limits and cost
12. Local testing and deployment from Cloud Build
13. When a function and when a service

Run through the abstraction continuum from 02-07 in your head, now with one more box:

Function as a Service takes abstraction to its practical extreme: you write a function — a unit of code with a specific signature —, the platform packages it, deploys it, runs it when something triggers it and shuts it down when it is not needed.

The four properties that define the model:

• It is triggered by an event. An HTTP request, a Pub/Sub message, a new file in a bucket, a modified document in Firestore. The function does not wait: it gets woken up.
• It scales to zero. With no events, there are no instances and no compute is paid for. A radical difference from a MIG VM, which costs the same at four in the morning as it does in the middle of a campaign.
• It scales up on its own. If a thousand events arrive at once, the platform starts instances. There is no autoscaler to configure.
• It is ephemeral and stateless. An instance processes and may disappear. Nothing saved in memory or on local disk survives reliably.

That last property is the hardest to internalise and the one that produces the most design errors. State lives outside: in Cloud SQL, in Firestore, in Cloud Storage, in BigQuery. A function that accumulates something in a global variable and expects to find it on the next invocation works in testing — because it reuses the same instance — and fails in production, intermittently and inexplicably.

This is the section you need to get right so as not to be misled by the old documentation still doing the rounds.

Cloud Functions was born in 2016 with a platform of its own. In 2022 the 2nd generation appeared, and the change is not cosmetic:

A 2nd generation Cloud Function is a Cloud Run service with a container built automatically by Google from your code, and its event triggers are Eventarc subscriptions.

Google builds the container for you using buildpacks, deploys it to Cloud Run and connects Eventarc so that events arrive as HTTP requests. Everything Cloud Run knows how to do, the function inherits.

The practical differences, which are the ones that matter when designing:

Concurrency is the most important difference. In the 1st generation, each instance served one request: 100 simultaneous requests meant 100 instances, with 100 cold starts and 100 database connections. In the 2nd, one instance with concurrency 80 serves 80 requests at a time, which drastically reduces cold starts, cost and pressure on Cloud SQL — a very real problem: the number of Cloud SQL connections is limited, and a badly sized 1st generation function exhausts the pool with astonishing ease.

The rule in 2026: always use the 2nd generation. --gen2 is mandatory in this lesson's examples. The 1st generation only shows up in old functions nobody has migrated.

And the natural question: if a 2nd generation function is a Cloud Run, why not use Cloud Run directly? It is an excellent question and it has an answer, but we leave it to section 13, when you have the context to weigh it up.

The Functions Framework is the library that turns an ordinary Python function into an HTTP service. It is installed like any other dependency and uses decorators.

The minimum structure of a function is two files:

Three details worth noting:

• The @functions_framework.http decorator marks the entry point. The name of the Python function (comprobar_stock) is what you pass to --entry-point.
• request is a Flask object. If you wrote the catalogue with Flask, the API is familiar: request.args, request.get_json(), request.headers.
• The return value follows Flask's conventions: a string, a (body, code) tuple or a complete response.

The deployment:

Each option, and why it is there:

--max-instances deserves an explanation, because its absence causes real incidents. With no ceiling, a traffic spike — or an infinite loop, or an attack — can start hundreds of instances that open hundreds of connections to alpinashop-pedidos and bring the database down. Infinite scaling is not a virtue if what is behind it does not scale the same way. Setting a limit turns a total outage into a partial degradation, which is infinitely preferable.

It is tempting to deploy with --allow-unauthenticated because "it is easier to test". That is exactly how data gets leaked.

A public function has a URL that is guessable from a known pattern, it is exposed to the whole internet, anybody can invoke it as many times as they like — and you pay for every invocation — and it usually has IAM permissions over databases and buckets in your project. It is a privileged endpoint with no door.

With --no-allow-unauthenticated, invoking the function requires the roles/run.invoker role — Cloud Run's, consistent with section 2:

And from the catalogue, the call is authenticated with an OIDC token:

The library obtains the token from the environment's identity — the service account attached to the GKE pod — with no key at all. It is the same mechanism as the push subscriptions with OIDC from 04-04.

The three cases in which a function can be public, and what is needed in each:

The webhook case deserves a note: a public function that receives payment notifications must validate the HMAC signature the provider includes in the header. Without that validation, anybody can send a POST saying "order 1234 is paid". It is a failure that shows up with depressing frequency.

An event-driven function does not receive an HTTP request: it receives a CloudEvent, an industry-standard format — not a Google invention — with common metadata (id, source, type, time, subject) and a payload specific to the event type.

In Python it is declared with @functions_framework.cloud_event:

Eventarc is GCP's universal event router. It receives events from more than 130 sources, normalises them to CloudEvents and delivers them to the destination. The most useful triggers:

The audit log trigger is the least known and one of the most powerful: it lets you react to any GCP API operation. For example, running a function every time somebody modifies a firewall rule in alpinashop-prod:

An important note about Cloud Storage: you can trigger directly from the bucket (storage.object.v1.finalized) or by publishing to a Pub/Sub topic and triggering from there. AlpinaShop chose the second option in 05-05, and the reason is solid: with Pub/Sub in the middle, several consumers can react to the same event. Today it only processes images; tomorrow, a second subscriber can update the search index without touching anything that already exists. With the direct trigger, every new consumer forces you to reconfigure the bucket.

Here the loose end from 05-05 is tied off. Let us recall the flow designed back then:

Step 1: notify the topic from the bucket. A single command, which is probably already done since 05-05:

The --object-prefix=productos/ avoids processing objects that are not product photos — logos, temporary files — and it is the cheapest way to filter: the event is not even generated.

Step 2: the function. It is commented block by block because each one solves a specific problem:

The three details that make this work in production, and that separate a tutorial example from real code:

The clients outside the function. Creating an ImageAnnotatorClient means resolving credentials and establishing connections: hundreds of milliseconds. By creating it at module level, it is created once per instance and reused across every invocation that instance serves. In a function with concurrency 20 and a thousand events, the difference is enormous.

The guard against the infinite loop (step 2). It is the classic mistake with functions triggered by Cloud Storage and it deserves a slow explanation: the function writes the thumbnail into the same bucket, which generates an OBJECT_FINALIZE event, which fires the function, which generates another thumbnail, which fires the function… Each iteration costs invocations, Vision API calls — which are billed — and rows in BigQuery. A loop like that discovered on a Monday morning may have burned through an entire budget over the weekend. The three possible defences are the prefix in the notification filter, the guard in the code and writing to a different bucket; use at least two.

The row_ids in insert_rows_json. BigQuery deduplicates by that identifier within a time window. It is a second net beneath the idempotency check in step 3.

Step 3: deploy it with its identity and its permissions.

--memory=1Gi is not a whim: opening a 12-megapixel product photo with Pillow consumes a fair amount of memory, and in the 2nd generation the allocated CPU grows with the memory, so it also runs faster. --retry enables retries, which is the subject of the next section.

This is the part that separates a function that works from a function you can trust. And it starts from a fact already established in 04-04:

Pub/Sub guarantees at least once delivery. Your function will receive duplicate messages. It is not a remote possibility: it is a statistical certainty.

Duplicates arrive for perfectly normal reasons: the function processed correctly but took longer than the acknowledgement deadline; there was a network failure while acknowledging; the instance restarted after processing and before acknowledging; or the event was redelivered because a previous invocation raised an exception.

Idempotent means that processing the same event N times produces the same result as processing it once. Let us analyse our function's three actions:

The third is the dangerous one, and that is why the design includes three layers of defence:

Layer 1, the stable identifier. gs://bucket/path#generation identifies a specific version of an object. Notice that the path alone would not be enough: if Dani uploads a corrected photo with the same name, it is a different object that does need reprocessing, and the generation distinguishes it.

Layer 2, the up-front check with a lightweight control table:

The 7-day window is a deliberate compromise: Pub/Sub duplicates arrive within seconds or minutes, not days, and limiting the query lets you take advantage of the table's partitioning instead of scanning the full history on every invocation. It is the same cost logic as in 04-01.

Layer 3, BigQuery's row_ids, which deduplicates automatically even if the previous two fail because of a race condition.

Retries. With --retry, if the function raises an exception, Pub/Sub receives no acknowledgement and redelivers the message. And here there is a design decision that is constantly got wrong:

A permanent error that gets retried is a function failing forever on the same message, consuming quota and filling the logs. The rule: only raise an exception if trying again has some chance of working.

Dead letter. Even with the distinction above, some message will fail indefinitely. The dead letter topic stops it blocking the queue:

After five attempts, the message goes to the DLQ instead of being retried forever. And a DLQ nobody looks at is worse than having no DLQ, because it creates a false sense of control: you have to put an alert on its number of unacknowledged messages — exactly the kind of alert configured in 06-04.

A function instance goes through three phases, and understanding which one is expensive explains almost all the observed behaviour:

The cold start is the time from the event arriving to your code starting to run: provisioning the instance, loading the runtime, importing the dependencies and running the module-level code. It ranges from a few hundred milliseconds to several seconds, and it depends above all on how heavy your imports are.

The five levers for mitigating it, ordered by real effectiveness:

When cold starts matter and when they do not, which is the decision you really have to make:

--min-instances costs money even with no traffic, and that is the price of partially giving up "scale to zero". Setting it by default on every function cancels out one of the model's economic advantages. Set it where a customer perceives the latency.

About concurrency, an important warning: with --concurrency=80, eighty requests run simultaneously in the same Python process. Any mutable global variable becomes shared:

The rule: at module level, only clients and constants. All mutable state, inside the function.

The three things every production function needs to have properly sorted.

Environment variables for non-sensitive configuration:

Secrets from Secret Manager, never as an environment variable carrying the value:

With that syntax, the function reads os.environ["API_KEY_PASARELA"] as normal, but the value is not in the deployment configuration: it is injected at run time from Secret Manager (03-06). Practical consequences: the value does not show up in the console, it is not left in the deployment history, it can be rotated without redeploying if you use :latest, and access is recorded in the audit logs. They can also be mounted as a file with --set-secrets='/etc/claves/api=secreto:latest', which is preferable for large values such as certificates.

And the detail that gets forgotten: the function's service account needs roles/secretmanager.secretAccessor on that specific secret, granted in the secret's policy.

Identity. By default, a function uses the project's Compute Engine service account, which usually has the Editor role — the same anti-pattern as in 06-01. Always --service-account with an account of its own per function. A function that only writes to BigQuery must not be able to delete buckets.

By default, a function lives outside your VPC: it can go out to the internet but it cannot reach resources with a private IP. If alpinashop-pedidos only has a private IP — as it should, according to 03-01 — a function cannot get there.

The bridge is a Serverless VPC Access connector:

Details that matter:

• The /28 range must be free and must not overlap with sn-web-euw1 or sn-datos-euw1. It is a strict requirement and a common source of errors.
• The connector is billed per instance and hour, whether it is in use or not. With --min-instances=2 you pay for two small machines permanently. It partially breaks "scale to zero", so it is shared between all the functions that need it.
• --egress-settings=private-ranges-only sends only traffic to private ranges through the VPC; the rest goes straight out to the internet. With all-traffic, everything goes through the VPC and out via the Cloud NAT alpinashop-nat-euw1 from 03-01, which gives a fixed egress IP — useful if a third party demands IP allowlisting.

Tip: do not add a connector "just in case". If the function only talks to Google APIs — Vision, BigQuery, Storage, like procesar-imagen-producto — it does not need one, and adding it is cost and complexity for nothing.

The 2nd generation limits worth keeping in mind — always check the current values in the official documentation:

Cost has four components, and there is a generous monthly free tier:

An indicative calculation for procesar-imagen-producto. Let us assume 20,000 images a month, 1 GiB of memory, 3 seconds per image:

• Invocations: 20,000 → covered many times over by the free tier.
• GB-second: 20,000 × 3 s × 1 GiB = 60,000 GB-s, mostly within the free tier.
• GHz-second: proportional, same order of magnitude.
• Real compute cost: practically zero.

And now the figure that really matters: the Vision API for those 20,000 images, with three features each, costs an order of magnitude more than the entire execution of the function. The economic lesson is that in event-driven architectures compute is almost never the main cost: the costs are the APIs you call and the data you move. Optimising the function's memory while making redundant calls to a paid API is optimising what does not matter.

That said, three ways for the bill to genuinely explode:

1. Infinite loops (section 6). The most expensive by a wide margin.
2. --min-instances on functions that do not need it. It is a fixed 24×7 cost and it cancels out the model's advantage.
3. A long timeout with hung errors. A function with --timeout=540s that sits waiting for a downed service pays nine minutes per failed invocation. Short timeouts, matched to reality.

Locally, the Functions Framework brings up a server:

And a Pub/Sub event is simulated with the real structure, base64 included:

Better still, unit tests that do not need anything brought up:

The first test deserves a comment: it verifies that the Vision API is not called for a thumbnail. It is the test that protects against the most expensive possible failure of this architecture, and it costs six lines.

Deployment from Cloud Build, fitting in with 06-01 and 06-02:

The Cloud Build service account needs roles/cloudfunctions.developer and roles/iam.serviceAccountUser over sa-procesar-imagen — this second permission is always forgotten and produces a permissions error that never mentions the word "function".

We come back to the question left open in section 2: if a 2nd generation function is a Cloud Run, why choose a function?

Choose Cloud Functions when:

• The work is one single thing triggered by an event: procesar-imagen-producto is the perfect example.
• You do not need system dependencies beyond the usual.
• You want the shortest path between "I have an idea" and "it is working".
• The team does not want to maintain Dockerfiles for every small piece.

Choose Cloud Run when:

• It is an application with several routes, like the Flask catalogue.
• You need to control the image: a specific version of a system library, a binary, a packaged model.
• You already have a container — AlpinaShop has had one since 02-05.
• You want real portability between GKE, Cloud Run and anywhere else.

For AlpinaShop, the allocation looks like this, consistent with decision DA-001 to move the catalogue to Cloud Run (developed in 07-02):

There is an anti-pattern that shows up when people like functions too much, and it is worth recognising before falling into it:

Six chained functions to process an order. It looks modular. In reality it is a monolith chopped up with network latency between its lines of code, and it inherits all the drawbacks of both worlds:

• Accumulated latency: six possible cold starts instead of one.
• Very difficult debugging: following a request means correlating six sets of logs. It is exactly the problem that the distributed tracing in 06-06 solves, but which it is better not to have.
• No transactions: if funcion-cobrar works and funcion-notificar fails, the system is left in an inconsistent state and has to be compensated by hand.
• Changes that cross six deployments: modifying the flow means coordinating six functions.
• Multiplied cost: six invocations and six times the overhead.

The warning sign is simple: if your functions call each other synchronously, they should probably be a single service. And if you really do need a multi-step stateful flow, the right tool is not chaining functions: it is Workflows, the orchestration AlpinaShop already chose in 04-06, which manages state, retries and errors explicitly.

Functions shine when they are leaves of the tree: they react to an event, do their job and finish. When they start becoming intermediate nodes coordinating others, they have been chosen badly.

The Cloud Storage infinite loop. A function triggered by a bucket that writes to that same bucket. It is the most expensive mistake in this lesson. Defend yourself with at least two of the three barriers: prefix in the notification filter, guard in the code and a different bucket for the outputs.

Assuming events arrive exactly once. They arrive at least once. Every event-driven function needs a stable identifier and an idempotency check. Without that, your data will have duplicates and you will not know why.

Retrying permanent errors. A corrupt image does not fix itself on the fifth attempt. Raise an exception only if retrying can work; for everything else, log it and return normally.

Creating the clients inside the function. Hundreds of milliseconds wasted on every invocation. Clients go at module level. But only clients and constants: any mutable global state is a race condition waiting for you to raise the concurrency.

Deploying with --allow-unauthenticated "just to test". That "just to test" sticks around. Use --no-allow-unauthenticated and grant run.invoker to whoever should be calling it.

Leaving the default service account. It is the Compute Engine one, with Editor. An account of its own per function, with the exact permissions.

Not setting --max-instances. A spike of events can open hundreds of connections to Cloud SQL and bring the database down. Unlimited scaling is not a virtue if what is behind it does not scale the same way.

Putting secrets into environment variables. Use --set-secrets with Secret Manager: it is not left in the configuration, it does not show up in the console and it is rotated without redeploying.

Adding a VPC connector "just in case". It costs money permanently. Only if you need to reach private IPs.

Using the 1st generation because you copied an old tutorial. --gen2 always: concurrency, more memory, more time and far more event sources.

And the tip that sums up section 13: if your functions call one another, stop and rethink. It is probably a service, or a Workflow.

AlpinaShop wants a function triggered by the pedidos-nuevos topic that sends a confirmation email to the customer and adds a row to the billing table in BigQuery. Sending an email is not idempotent: the customer is annoyed if they receive three. Design the function explaining the idempotency mechanism, which errors you would retry and which you would not, and what deployment configuration you would use. Point out the exact place where a race condition could produce a duplicate email and how you would mitigate it.

For each of these four AlpinaShop cases, choose Cloud Function, Cloud Run or Workflows, and justify the decision with criteria from this lesson: (a) generating the PDF invoice for an order, about 2 seconds per invoice, triggered after payment; (b) the internal administration panel, about 30 HTTP routes, used by 5 people during office hours; (c) the nightly process that recalculates recommendations, about 40 minutes, with 6 dependent sequential steps; (d) resizing images from customer reviews, with spikes of 500 images within a few minutes after a campaign.

One Monday, Marta sees that the weekend's bill has been 40 times the usual. The data: procesar-imagen-producto recorded 1.2 million invocations in 48 hours against the usual 600; the imagenes_vision table has 1.2 million new rows, many of them with the same ruta_gcs; the alpinashop-catalogo bucket has grown by 300 GB; and the imagenes-subidas-dlq DLQ is empty. On Friday a "minor" change was deployed: also saving a black and white version of each photo. Diagnose the cause, explain why the empty DLQ is a clue rather than a reassurance, and detail the immediate containment and prevention measures.

Solution 1

The core problem: the function has two effects with opposite properties. Inserting into BigQuery is controllable with row_ids; sending an email is irreversible. Once it is sent, there is no undo.

Idempotency mechanism with a marker before sending. The key is to record the intention before the irreversible action, with an atomic conditional write. Firestore fits better than BigQuery here because it offers transactions and low latency:

Error classification:

Deployment:

--min-instances=1 is justified here: a customer who has just paid is waiting for their confirmation, and two seconds of cold start at that moment are noticeable.

The race condition and its mitigation. The gap is between the create() and the send_confirmation_email(). If the instance dies right there, the reservation stays in the sending state forever and the customer never receives the email, because redeliveries will see the reservation and back off.

The code mitigates it with the 300-second timer: a sending reservation older than that is considered orphaned and is retried. The trade-off is explicit and has to be accepted: if the instance did not die but simply took a long time, two emails will be sent.

And here is the underlying lesson: with an irreversible external action there is no such thing as an exactly-once guarantee. You can only choose which side to fail on:

For a confirmation email, an occasional duplicate is annoying but harmless, whereas not sending it generates a call to customer support. That is why the timer is the right choice here. For a card charge, the answer would be the opposite, and the appropriate solution would go through an idempotency key from the payment provider itself.

Solution 2

(a) Invoice PDF: Cloud Function. It is the canonical case: one event, one bounded action, 2 seconds of work, no exotic dependencies. Triggered by pedidos-nuevos or by a dedicated "payment confirmed" topic, with --memory=512Mi and a moderate --max-instances. Nuance: if generating the PDF needed corporate fonts or LaTeX, the system dependency would push towards Cloud Run with a container of its own.

(b) Administration panel: Cloud Run. Thirty HTTP routes are an application, not a function. A Cloud Function has one entry point, and putting a router inside it would be using the tool backwards. Besides, the usage pattern — five people during office hours — makes scaling to zero at night and at weekends ideal, and that is precisely Cloud Run. --min-instances=0, and if the cold start bothers people first thing in the morning, --min-instances=1 during working hours only. It is consistent with DA-001.

(c) 40-minute nightly recalculation: Workflows. Two reasons, each sufficient on its own. First, 40 minutes exceeds the 9-minute limit of an event-driven function. Second, and more important: six dependent sequential steps are orchestration, and chaining them with functions would be the distributed monolith from section 13. Workflows — already chosen in 04-06 — manages state, per-step retries and errors explicitly, and each step invokes whatever is appropriate: a Cloud Run Job, a BigQuery job or a Vertex AI pipeline.

(d) Resizing review images: Cloud Function. It is identical to procesar-imagen-producto: one event, one action, no state. The spikes of 500 images are exactly where the model shines — it scales on its own and goes back to zero afterwards. Configuration: --memory=1Gi, --max-instances=100 so that the spike is absorbed quickly, --min-instances=0 because nobody is waiting in real time, and --retry with idempotency by generation.

The criterion that unifies all four: count how many different things the piece does and how long it takes. One thing and little time → function. Many routes → service. Many coordinated steps → workflow. And when you hesitate between a function and a service for something that is already containerised, Cloud Run almost always wins on portability.

Solution 3

Diagnosis: an infinite loop, exactly the one from section 6.

Friday's "minor" change added writing a black and white version into the same bucket, and in all likelihood into a prefix that is not productos/miniaturas/, which is the only thing the guard in the code checks. Reconstructing the sequence:

1. productos/piolet.jpg is uploaded → event → the function processes it.
2. It writes productos/miniaturas/piolet.jpg → event → ignored by the guard. Correct.
3. It writes productos/bn/piolet.jpg → event → the guard does NOT cover it → it is processed.
4. Processing productos/bn/piolet.jpg writes productos/bn/bn/piolet.jpg → event → it is processed…

Each level generates the next one. The growth is exponential until something stops it. All four pieces of evidence fit without exception: 1.2 million invocations (recursion); repeated rows with the same ruta_gcs in imagenes_vision (each level writes a row, and idempotency does not protect you because each derived object is a different path); 300 GB of growth (the generated objects); and the runaway bill, dominated by the Vision API, not by the function.

Why the empty DLQ is a clue rather than a reassurance. Instinct says "the DLQ is empty, nothing has failed". It is exactly the other way round: the empty DLQ confirms that everything worked correctly. The function had no errors at all; it did perfectly what it was asked to do, one million two hundred thousand times. That is the danger of event-driven systems: the expensive failure does not produce errors, it produces successes. No alert based on error rate would have caught this. What would have caught it is an alert on the volume of invocations — a subject for 06-04 — and its absence is the real finding of the incident.

Immediate containment, in this order:

Setting --max-instances=0 instead of deleting the function is deliberate: it stops the bleeding immediately, it preserves the whole configuration for the diagnosis and it is reversible with one command.

Clean-up: delete the derived objects recursively (productos/bn/bn/... and onwards) keeping the first level if it turns out to be useful; remove from imagenes_vision the rows whose ruta_gcs contains /bn/; and check whether any downstream process — the search index, productos_color from 05-05 — consumed that data and needs to be redone.

Prevention, in five measures:

The third measure is the most transferable design lesson. The original guard was a blocklist: "if it starts with productos/miniaturas/, ignore it". A blocklist fails whenever a new case appears, and one will. The right thing is an allowlist:

With that version, Friday's change would have been harmless: the function only processes what is explicitly permitted. In an event-driven architecture, forbidding the known is fragile; permitting only the known is robust.

And the final reflection on the incident: there was no technical failure. There was a one-line change, reviewed by nobody, in a system where writing to a bucket means triggering code. Three things would have prevented it and all three are in this module: the code review from 06-02 — somebody would have asked where the new file gets written —, the unit test from section 12 — which verifies that Vision is not called for derived objects —, and the observability from 06-04 — a volume alert that warns you within minutes. The 40× bill is the price of having none of the three.

Module 5's loose end is tied off. procesar-imagen-producto exists, it fires from imagenes-subidas, it calls the Vision API, it generates the thumbnail, it writes to alpinashop_analitica and it wakes nobody up in the middle of the night.

You know what FaaS is and what its deployment unit is — the function —, with the four properties that define it: it is triggered by events, it scales to zero, it scales up on its own, and it is ephemeral and stateless, with the practical consequence that everything that has to survive lives outside.

You understand what a 2nd generation Cloud Function is today: a Cloud Run service with a container built by Google and triggers managed by Eventarc. And you know what that gives you — configurable concurrency instead of one request per instance, up to 60 minutes over HTTP, up to 32 GB, traffic splitting and more than 130 event sources — with the clear rule of always using --gen2.

You know how to write an HTTP function with the Functions Framework and deploy it with the options that matter, --max-instances included, because unlimited scaling is not a virtue if Cloud SQL does not scale the same way. And you know that almost no function should be public: --no-allow-unauthenticated, run.invoker to whoever needs it and an OIDC token in the caller, with the three legitimate exceptions and what each of them demands.

You know event-driven functions, CloudEvents and the table of what triggers what — Pub/Sub, Cloud Storage, Firestore and the audit logs — and why AlpinaShop goes through a topic instead of triggering straight from the bucket: so that tomorrow a second consumer can react without touching anything.

You have the complete case solved, with the three details that make it viable in production: clients created at module level, the guard against the infinite loop and BigQuery's row_ids. And you have the discipline that separates a function that works from one you can trust: idempotency with a stable identifier — path plus generation —, a time-bounded up-front check and deduplication at the destination; the distinction between transient errors that get retried and permanent ones that do not; and a dead letter with an alert, because a DLQ nobody looks at is worse than not having one.

You know what a cold start is, the five levers for mitigating it and — more importantly — when it matters and when it does not: --min-instances where a customer perceives it, zero in batch processing. You know the danger of mutable global variables with high concurrency, with the rule that only clients and constants go at module level. You know how to inject configuration with environment variables and secrets with --set-secrets from Secret Manager, give each function its own service account, and connect to the VPC with a connector when — and only when — you have to reach a private IP.

You have the limits and the cost with its indicative calculation, and the economic lesson that goes beyond the example: in an event-driven architecture, compute is almost never the main cost; the costs are the APIs you call and the data you move. You know how to test locally, write the six-line unit test that protects against the most expensive possible failure, and deploy from Cloud Build.

And you have the criterion from section 13: a function for one thing triggered by an event, a service for an application with many routes, a workflow for several coordinated steps, with the warning against the distributed monolith of functions and its warning sign — if your functions call each other synchronously, rethink it.

Now look at the state of AlpinaShop. There is a shop on GKE, a function processing images, data pipelines, models training themselves, a CI/CD pipeline and a network infrastructure holding all of that up. Lots of pieces. Many more than fitted three modules ago.

And there is still only one way to know whether they work: a customer writing an email to say the website is slow.

That is the problem in 06-04. It is time to stop looking at the console and start measuring: metrics, dashboards and alerts with Cloud Monitoring, so as to find out about problems before the customers do.