Lesson 2: The Standard Integration Profile

Why a profile comes before a product

In Level 1 you saw every Google Cloud integration service on one page, sorted into groups: queues, publish-subscribe, event routing, workflow and orchestration, API management and connectors. The obvious next step is to start comparing products. Don't do that yet.

Teams that start with a product ("we use Pub/Sub, so this goes on Pub/Sub") end up forcing the job to fit the tool. A better habit is to describe the job first, in numbers, and only then let services compete for it. That description is the standard integration profile. Think of it as a building survey done before choosing materials. You measure the load and then pick the beam. Every service lesson from Level 3 onwards scores against this same profile, so the time you spend here pays off later.

The profile has twelve entries:

Turning vague words into numbers

Stakeholders say "real-time" and "reliable". Neither word can be tested. Your job in the interview is to translate each one into a number:

• "Real-time" → "p99 end-to-end latency under 2 s." Ask: if this took 30 seconds, what breaks? Often nothing does, and that alone opens up the asynchronous options.
• "Reliable" → two separate entries: zero lost messages and an acceptable duplicate rate. Most messaging systems deliver at least once by default. Pub/Sub, for example, offers exactly-once delivery only on pull subscriptions, only within one region, and only when you switch it on. So ask: what happens if a customer is charged twice? If the answer is "disaster", record "duplicates: 0 effects, consumer must be idempotent". Don't write "exactly-once required" and stop there.
• "High volume" → average and peak messages per second, plus the shape of the peak (a Black Friday spike or a nightly batch).
• "Big files" → the largest payload in KB or MB. This number rules things out quickly, as the next section shows.

Gotcha: always record the peak, not the average. A 20 msg/s average with a 1,500 msg/s flash-sale peak is a different job from a steady 20 msg/s.

Worked example: order processing

Here is a filled-in profile for an online shop's order flow. Keep it as YAML in the repo next to the code, so it gets reviewed like code.

# integration-profile.yaml: order processing, interviewed 2026-10-30
job: order-processing
sync_or_async: async          # checkout returns "order received" immediately; the rest happens later
message_kind: events           # "OrderPlaced" is a fact; payment, stock, email each react to it
ordering:
  required: per_key            # events for ONE order must stay in sequence
  key: order_id                # global ordering is NOT needed (and is expensive)
delivery:
  loss_allowed: false
  duplicate_effects_allowed: 0 # charging twice is unacceptable -> idempotent consumers
  duplicate_deliveries_ok: true  # receiving twice is fine if the handler dedupes on order_id
message_size:
  typical_kb: 4
  max_kb: 64                   # invoice PDFs go to Cloud Storage; only a link travels
volume:
  avg_msgs_per_sec: 20
  peak_msgs_per_sec: 1500      # flash sale, ~2 hours, 4 times a year
latency:
  p99_end_to_end_ms: 5000      # "real-time" turned out to mean "email within 5 s"
fan_out: 4                     # payment, inventory, email, analytics
long_running:
  max_duration: 14d            # returns window; refund needs a human approval
  human_steps: true
partners_saas: [stripe, sendgrid]
api_consumers:
  external: false              # only our own frontend calls in
  auth: service accounts (internal)
team:
  skills: [python, terraform, cloud-run]
  ops_appetite: low            # 3 engineers, no one on call for brokers
cost_model_preference: pay_per_use   # spiky traffic suits per-message pricing over fixed tiers

Notice the split between duplicate deliveries and duplicate effects. That split is the most useful thing a senior engineer brings to these interviews. You will rarely get a guarantee that a message arrives once. What you can guarantee is that processing it twice does no harm.

Screening out service groups early

With the profile filled in, cross off whole groups before looking at any single product. Here is a rough first pass for the order profile:

Entry                    -> Effect on the groups from Level 1
message_kind: events     -> favours publish-subscribe and event routing over plain queues
fan_out: 4               -> a point-to-point queue alone would need 4 copies; pub-sub fits better
long_running: 14d, human -> needs workflow/orchestration for the refund path
api_consumers: internal  -> full API management (developer portal, monetisation) is likely overkill
partners_saas: 2 APIs    -> plain HTTP calls are enough for now; connectors stay a "maybe"
max_kb: 64               -> fits every messaging service (dated limits below)

The screening only works if you know the limits that bite, so here are a few to keep in mind. They are dated October 2026; check the quota pages before you rely on them:

• Pub/Sub: message data up to 10 MB.
• Cloud Tasks: task size up to 1 MiB; a task can be scheduled at most 30 days ahead.
• Workflows: one execution can run for up to 1 year.
• Cloud Run: a request times out after at most 60 minutes. A 14-day refund process can't be one HTTP call.

If your profile said max_kb: 5000, Cloud Tasks would drop out at once. If it said long_running: 14d, any design built on a single synchronous request would drop out too.

Trade-off: screening is for ruling things out, not for picking a winner. Two or three groups usually survive, and one job often needs more than one. Here that means pub-sub for fan-out plus orchestration for refunds. You will score the survivors with a weighted scorecard later in the course.

A second quick profile: partner onboarding

It helps to contrast. A B2B partner onboarding flow might read like this: sync API calls from partners, commands ("create account"), no ordering, low volume (50 per day), large documents (KYC scans up to 20 MB), multi-day approvals, Salesforce and SAP involved, external API consumers needing OAuth and per-partner quotas. That profile points at API management, connectors and orchestration. It points away from high-throughput messaging. Same company, different job, different groups.

Key takeaways

• Fill in the profile before naming any product. All twelve entries, in numbers where possible.
• Translate "real-time" into a p99 latency and "reliable" into loss allowed and duplicate effects allowed.
• Record peak volume and maximum payload size. Those are the numbers that rule services out.
• Plan for at-least-once delivery and make consumers idempotent. Don't count on exactly-once.
• Use the profile to cross off whole service groups first. Expect two or three to survive, sometimes in combination.
• Keep the profile in version control, dated, so later scoring can be traced back to it.