Choosing services: a guided design walkthrough

Eleven weeks after Owen's first morning, Farah hands him a one-page brief and an empty whiteboard. "You have every piece now," she says. "Design the new returns platform end to end, and explain each choice the way you would to Dana, Jules and Teresa. I will play all three." This final lesson follows that design session. It brings together location, hierarchy, identity, billing, compute, storage, databases, networking and operations, and shows a method Owen can use for any design question, including the scenario questions on Google Cloud exams.

The brief

Birchline accepts about 9,000 returns a month online and in stores, rising to about 30,000 in January after the holidays. Today, returns are handled by an old internal app on a single server plus a lot of email. The new platform must let shoppers start a return on the website, print a label, and track it; let store staff and warehouse staff check in returned items; store photos of damaged items; tell the inventory system when items are back in stock; and give the finance and data teams reporting. The requirements Farah writes on the board:

• Customer data stays in Canada, and photos of returned items must be kept for two years and then deleted.
• The customer-facing part must be available during store hours and should cope with the January surge without manual work.
• Staff sign in with their Birchline accounts; shoppers sign in with their shop accounts.
• Monthly running cost should be predictable, and close to zero for parts that are idle overnight.
• The team is small: three developers and Owen.

A method for design questions

Farah's method has five steps, and Owen writes them in the corner of the whiteboard. First, list the requirements and constraints, separating must-haves from preferences. Second, sketch the data: what is stored, its shape, how often it is read and written, and how long it must be kept. Third, choose the most managed service that meets each need, moving toward more control only for a stated reason. Fourth, add the cross-cutting layers: location, hierarchy, identity, network, operations and cost. Fifth, check the design against every requirement and note the trade-offs.

The same method works for exam questions. Scenario questions usually contain a few decisive phrases, such as must not manage servers, needs a specific operating system, global consistency, the lowest cost for rarely accessed data, or already uses Kubernetes. Underlining those phrases, and eliminating options that violate any of them, is often enough to find the answer.

Step 2: the data

Owen considers Firestore for return requests, because the mobile app might show return status. He decides against it: returns link to orders, items, refunds and stores, finance needs transactional correctness, and Birchline's team already knows SQL. Spanner is not needed either, because the data is regional and well within Cloud SQL's capacity. He writes the reasoning down, because Farah's next question is always why not the other one.

Step 3: compute

The platform has three pieces of code: a web front end and API for shoppers and staff, a function that makes thumbnails of uploaded photos, and a nightly job that loads data into BigQuery. All three are new, stateless and containerizable, and the team is small, so the most managed options win.

Owen checks Compute Engine and GKE against the brief and records why neither is needed: nothing requires operating system control, and the team does not need Kubernetes. If a future requirement appears, such as a vendor component that only runs on a particular Linux, a small managed instance group could be added without changing the rest.

Step 4: the cross-cutting layers

Location. Everything runs in northamerica-northeast2 (Toronto). Cloud SQL uses its high availability configuration across two zones, with automated backups and a cross-region read replica in Montréal for recovery. The photo bucket is regional, in the primary region, because photos can be re-uploaded in the rare event of a regional disaster and a dual-region bucket would cost more. The organization policy on locations already prevents anything being created elsewhere.

Hierarchy. Two new projects, bl-returns-prod in the Production folder and bl-returns-dev in Non-production, so production access and budgets stay separate. Both carry the four required labels. Terraform creates both projects and their resources from the same code.

Identity. Staff sign in through Identity-Aware Proxy in front of the staff pages, using their Cloud Identity accounts and a group, returns-staff@birchline.example; shoppers sign in through the shop's existing customer accounts, which the app checks. Each component runs as its own service account: returns-app has Cloud SQL Client and Storage Object Admin on the photo bucket only; thumbnailer has object access on the same bucket; inventory-updater can call the inventory API; reporting-job can write to one BigQuery dataset. Developers get Cloud Run Developer on the dev project and read-only roles on production. No keys are created.

Network. The shopper and staff entry point is the existing global external Application Load Balancer, with a new path rule and Cloud Armor. Cloud Run reaches Cloud SQL over a private IP address in the Shared VPC, so the database has no public address. The inventory system, still on Compute Engine, is reached privately on the same network.

Operations. Uptime checks on the shopper and staff pages; alerting policies on error rate, p95 latency and Pub/Sub messages waiting too long; an SLO of 99.5 good requests in every 100 during store hours; logs to the _Default bucket for 30 days with the organization's audit sink unchanged; Error Reporting and Cloud Trace enabled. Runbooks for the three alerts are written before launch.

Cost. Owen estimates the monthly bill with the pricing calculator, using illustrative figures in his model below. Cloud Run and the function scale to zero overnight; the Cloud SQL instance is the steady cost and a candidate for a committed use discount after three months; photo storage grows until the two-year lifecycle rule starts deleting. A budget on the two projects alerts the team and Dana's finance group.

# Illustrative monthly estimate, not current list prices.
returns_per_month = {"typical": 9000, "january": 30000}
photo_mb = 3.0
photos_per_return = 1.5
storage_price_per_gb = 0.02
cloud_sql_monthly = 260.0        # small HA instance, always on
run_cost_per_1000_returns = 1.10 # requests, CPU and memory while busy

for label, n in returns_per_month.items():
    new_photo_gb = n * photos_per_return * photo_mb / 1024
    run_cost = n / 1000 * run_cost_per_1000_returns
    print(f"{label:8} new photos {new_photo_gb:6.1f} GB, Cloud Run about {run_cost:6.2f}, Cloud SQL {cloud_sql_monthly:.2f}")

two_year_gb = (9000 * 11 + 30000) * 2 * photos_per_return * photo_mb / 1024
print(f"photo storage after two years: about {two_year_gb:,.0f} GB, costing about {two_year_gb * storage_price_per_gb:,.2f} a month")

typical  new photos   39.6 GB, Cloud Run about   9.90, Cloud SQL 260.00
january  new photos  131.8 GB, Cloud Run about  33.00, Cloud SQL 260.00
photo storage after two years: about 1,134 GB, costing about 22.68 a month

The model shows what matters for this design: the database is the main fixed cost, compute follows the number of returns, and photo storage stays modest because of the lifecycle rule. Dana gets her predictable number, with January's surge visible in advance.

Step 5: checking the design

Farah, playing Teresa, asks what happens if the photo bucket is made public by mistake. Owen points to public access prevention enforced by organization policy. Playing Jules, she asks how a bad release is undone. Owen answers with Cloud Run revisions and traffic splitting. Playing Dana, she asks what the bill will be in January. Owen shows the model and the budget. Then, as herself, she asks the question she always asks: what would you change if the brief changed? Owen has an answer for three cases: a global expansion would point toward Spanner and a dual-region bucket; a vendor component would add a small managed instance group; heavy mobile use might add Firestore for status updates.

From design to delivery

A good design is only the start. Farah asks Owen how the returns platform will be built and released, and he sketches the delivery path beside the architecture. The Terraform code for both projects lives in the platform team's repository and is applied through a pipeline after review. The application code lives in the returns team's repository; each merge triggers Cloud Build, which runs the tests, builds a container image, stores it in Artifact Registry and deploys it to the development project. Promotion to production is a deliberate step: the same image is deployed to bl-returns-prod as a new Cloud Run revision that first receives a small share of traffic, about one request in ten, while the team watches the error and latency alerts.

The migration from the old returns app is planned in the same spirit. Open returns are copied to Cloud SQL with a one-off script, staff are trained in two stores first, and the old app is kept read-only for a month so that anyone can look up an old return. Only after January's surge passes cleanly is the old server switched off for good, which removes one more machine from the room behind the warehouse.

Owen photographs the whiteboard. It is the first architecture he has designed for the cloud, and every box has a reason written next to it. Farah tells him it is ready for review by the platform team, and that he is ready for GCP-102, where the same thinking is applied to the business questions on the Cloud Digital Leader exam.