Google Solutions Architect (Mid-Level) Interview Preparation Guide

Direct answer
Do not quietly absorb the cut. Compute what half the money actually buys, rank the scope by business value with the client, and offer a recommended option: roughly half the scope in 3 months, built so the highest-value half is complete and usable, with the rest priced as a funded second phase. Show the alternatives (full scope later, or full scope now) and why they do not work: full scope later fits the monthly rate but still costs the original total, and full scope now needs the original team.

Step 1: capacity arithmetic (illustrative)
Assumption: the cut maps directly to team size at the same rates, so a 50% budget cut means half the people. Original plan: 8 people for 3 months = 24 person-months. With 50% of the budget: 4 people for 3 months = 12 person-months. Keep a 15% buffer: 12 x 0.85 = 10.2, so commit about 10 person-months.

Step 2: decide what to cut
Rank by value to the client's outcome (asked of them, not guessed), dependencies, effort and risk. Value per person-month shows what each month of effort buys.

Why Phase 1 is A + C + G: A and C come first on value per month (8 and 5), using 8 of the 10 committed months. Only 2 months remain, and B needs 4 and D needs 3, so neither fits; G needs 2 and does. A + C + G = 60 points. The next-best set that fits, A + B at 9 months, gives only 55. If the client says the ERP integration is the reason they bought, the ranking changes and I would swap: A + B, dropping C and G.

Step 3: phased plan

• Phase 1 (3 months, funded now): A + C + G = 10 person-months, 60 of the 100 value points.
• Phase 2 (new funding, date by agreement): B + D = 7 person-months, 25 points.
• Phase 3 (optional): E + F = 7 person-months, 15 points.
  Phase 1 is a complete usable product, not half-built features.

Step 4: negotiate
Open with the arithmetic, not an apology. For example: "With the budget halved, the team that fits is four people, which is about 10 person-months of work over the three months. The full scope is 24. I would like to walk through the list with you and agree which half matters most for your launch. Here are three ways forward." Offer three options: (1) half scope in 3 months (recommended), (2) full scope at the reduced run rate (the monthly spend the new budget allows), which takes about 6 months (24 / 4) but spends 24 person-months, double the 12 that the halved budget buys, so it only works if the client funds the other half over the extra three months, (3) full scope in 3 months, which needs the original team and is not possible at this budget. Ask the client which outcome matters most.

Step 5: paperwork
A written change order (a signed amendment to the contract) changing the statement of work (the document listing what we deliver): reduced scope, new acceptance criteria (the conditions the client uses to accept the delivered work), what is deferred, and a dated option to fund Phase 2.

Pitfalls
Cutting evenly across everything (everything half-done), cutting quality silently, or promising the old scope with the hope of finding savings later.

Direct answer

Before sketching anything, I separate three questions: who is this for and what must it do (functional scope), what quality bar does it have to hit (non-functional requirements like scale, latency, and compliance), and what am I explicitly choosing to leave out for this iteration. I get there by asking a short list of targeted questions, writing down the assumptions I have to make when answers aren't available yet, and drawing an explicit line between what ships now and what's deferred, instead of letting scope grow implicitly as the conversation continues.

Structured elaboration

A repeatable order of operations

1. Clarify the primary user and the one core job the service must do for them.
2. Ask about scale and growth (expected load today, expected growth rate, read-versus-write ratio), because these numbers, not taste, determine how much architecture is actually warranted.
3. Ask about non-negotiable constraints: compliance obligations, systems it must integrate with, budget, deadline.
4. Ask what's allowed to degrade: is a few seconds of staleness acceptable, is brief downtime during a deploy acceptable, does every read need to be exact.
5. State assumptions explicitly wherever a real answer isn't available yet, and mark them as assumptions to validate, not facts to build on silently.
6. Draw the scope line: list primary use cases that must ship, and secondary or deferred use cases that are explicitly out of scope for this iteration, written down so nobody discovers the gap later.

The judgment underneath the checklist
A senior candidate treats every "yes, and also" as a scope decision with a cost, not a free addition, and pushes back on a vague ask like "make it fast" by translating it into a testable target before designing a single component, which is the same move a strong answer makes when a client says a product must "feel fast" for users worldwide.

Worked example

Take the one-line prompt "design a URL shortener." Before sketching components, I'd ask: how many new links are created per day, and what's the read (redirect) to write (creation) ratio? Suppose the answer is 10,000 new links/day with a 100:1 read-to-write ratio, typical of a link-sharing product:

$\text{redirects/day} = 10{,}000 \times 100 = 1{,}000{,}000$

$\text{avg redirect RPS (requests per second)} = \frac{1{,}000{,}000}{86{,}400} \approx 11.6 \text{ req/s}$

That single clarifying question, the read-to-write ratio, turned a vague prompt into a concrete, low-single-digit-RPS system, which tells me this is a read-heavy, cache-friendly problem, not a write-scaling problem, before a single box has been drawn. If the interviewer instead says the product is a bulk-import tool with a roughly 1:1 read-to-write ratio, the answer to nearly every later design question changes, which is the point: the clarifying question, not the diagram, is where the real design decision happens.

Scope line for this example: in scope for a first version is create-and-redirect with a randomly generated short code. Explicitly out of scope for the first version, stated to the interviewer rather than silently dropped, are custom vanity aliases, click analytics, and link expiration, each a real feature with its own cost that can be added once the core path is validated.

Trade-offs & pitfalls

• Designing before scoping: sketching a box diagram before knowing the read-to-write ratio, scale, or constraints wastes limited interview time on a shape that may not fit the real problem.
• Silently assuming numbers instead of stating them, so a listener can't tell you're reasoning from an assumption rather than a fact.
• Treating scope-cutting as a failure rather than a design decision; a strong candidate narrates what they are choosing not to build and why, instead of trying to design everything at once.
• Requirements-gathering theater: asking a long, generic checklist of questions instead of the two or three that would actually change the design.

Direct answer

Non-functional requirements (NFRs) describe how well the system must behave rather than what features it has. In enterprise discovery I make sure to capture nine areas: performance, throughput and scalability, availability, disaster recovery, security, compliance and data residency, integration, operability, and data volume and retention. For each I refuse a qualitative answer ("fast," "very secure") and ask for a number or an acceptance test the customer would sign off. I also write down which numbers are hard requirements and which are goals, because that distinction drives the architecture and the price.

The requirements and what I ask for

Those are the nine requirements. For each one the customer raises, I ask at least one follow-up. Integration deserves the most: "Is the interface synchronous (the caller waits for the reply)? What happens to messages if their system is down?"

Making the numbers meaningful

Availability numbers sound small but differ a lot. Over a 30-day month (43,200 minutes):

• 99.9% allows 43,200 x 0.001 = 43.2 minutes of downtime.
• 99.99% allows 43,200 x 0.0001 = 4.32 minutes.

Two components in series each at 99.9% give 0.999 x 0.999 = 0.998001, about 99.8%, so a customer who needs 99.9% end to end needs better than 99.9% for each part. Worked backwards for two equal parts, each needs the square root of 0.999, about 0.9995, so 99.95% each (check: 0.9995 x 0.9995 = 0.99900025). That is 21.6 minutes of downtime per month per part, not 43.2. I use this to show why a requirement stated for the whole system changes component choices. A customer asking for 99.99% should be asked what an hour of downtime costs, because the cost of that extra nine (one more 9 in the percentage, 99.9% to 99.99%, which allows ten times less downtime) is large, and the answer might show 99.9% is enough.

Acceptance criteria

I turn each into a test: "P95 under 500 ms at 200 RPS, measured on a copy of production data for 30 minutes" is acceptable; "should be responsive" is not. Those become the success criteria for any proof of concept (a limited trial against agreed criteria).

Pitfalls

• Accepting "same as today": measure today's performance first, or you promise what you cannot verify.
• Mixing hard requirements with wishes. Ask "what happens if we miss this?"
• Forgetting the owner of each integration: the technical contact for system A rarely speaks for system B.

Direct answer

DNS-based failover works by changing the authoritative record (A, AAAA, or CNAME) for a name once a health check detects the current target is down, so future lookups resolve to the healthy endpoint. The catch is caching: recursive resolvers, OS stub resolvers, and some client libraries hold the old answer and are not obligated to re-check before the TTL expires, so a client that resolved the name right before the failure can keep sending traffic to a dead endpoint for up to a full TTL, even though the authoritative record already changed.

Structured elaboration

sequenceDiagram
    participant Client
    participant Resolver
    participant AuthDNS as Authoritative DNS
    participant HealthCheck as Health Checker
    participant OriginA as Origin A (primary)
    participant OriginB as Origin B (standby)

    Client->>Resolver: Resolve api.example.com
    Resolver->>AuthDNS: Query (cache miss)
    AuthDNS-->>Resolver: A record = Origin A (TTL 300s)
    Resolver-->>Client: Origin A (cached 300s)
    Client->>OriginA: Request
    Note over OriginA: Origin A fails
    HealthCheck->>OriginA: Health probe fails twice (60s)
    HealthCheck->>AuthDNS: Update A record to Origin B
    Note over Client,Resolver: Cache still holds Origin A until TTL expires
    Client->>OriginA: Request still routed to dead origin
    Note over Resolver: TTL expires
    Client->>Resolver: Re-resolve api.example.com
    Resolver->>AuthDNS: Query (cache miss)
    AuthDNS-->>Resolver: A record = Origin B
    Client->>OriginB: Request now routed correctly

How TTL bounds the blast radius. The authoritative TTL is an upper bound, not the whole story. Worst case for a client is roughly detection time (how long health checks take to notice the endpoint died) plus record update propagation (usually seconds for managed DNS) plus up to a full TTL for a resolver that cached the record right before the failure. Best case is a client whose cache had already expired at the moment of failure, seeing the change almost immediately.

Reducing client-visible downtime

• Shorten TTL ahead of planned risk windows (deploys, maintenance) at the cost of more DNS query volume.
• Put a health-checked global load balancer or CDN in front of origins: it does fast, active health checking and reroutes without waiting on client-side DNS caches at all, since clients only ever resolve to the load balancer's stable address.
• Use anycast so the same IP is announced from multiple locations and failover happens at the routing layer, bypassing DNS caching entirely.

Worked example

Health checks poll every 30 seconds and require 2 consecutive failures before triggering failover, to avoid flapping on a single missed check: detection time = 60 seconds. A managed DNS provider's record update completes in about 5 seconds.

At TTL = 300 seconds, worst-case client-visible downtime (client cached the record 1 second before failure):

Best case, client's cache had already expired at the moment of failure:

If TTL is tuned down to 30 seconds ahead of a risky change:

That is a 3.8x improvement in worst-case client-visible downtime, but caches now expire 10 times more often ($300/30$), meaning roughly 10 times more queries hit the authoritative nameservers for the same client population, a real cost and load trade-off, not a free win.

Trade-offs & pitfalls

• Some resolvers and client libraries do not strictly honor TTL, a small minority cache longer or shorter than instructed; design for the worst case, not the documented one.
• Setting TTL near zero everywhere, permanently, trades a failover problem for a cost and latency problem, since every request now pays a fresh DNS lookup and some providers charge per query.
• DNS failover alone cannot verify the new target is actually healthy from the client's network path; combine it with active health checks at the load balancer or CDN layer rather than relying on DNS as the sole signal.
• A common mistake is failing over DNS but leaving the client's connection pool holding an open connection to the dead endpoint. DNS failover only affects new lookups, not already-established connections, so client-side connection timeouts and retry logic matter just as much as the TTL.

Direct answer

Because Cloud SQL cross-region replicas require a human to promote them, there is no automatic cross-region failover the way there is within a single region, the design has two halves: an asynchronous cross-region read replica kept close enough to the primary that promoting it loses at most 5 minutes of data (the recovery point objective, RPO), and a documented, rehearsed promotion runbook a paged, half-awake engineer can execute in well under 30 minutes (the recovery time objective, RTO). The 30-minute number is really a statement about how fast your team acts, not about anything GCP automates for you across regions.

How the pieces fit together

Replica topology and RPO

A cross-region asynchronous replica in a second region is the backbone. Replication lag is your RPO in practice: under a steady 100GB-scale write load, lag is typically seconds, but you have to actually monitor the replica-lag metric and alert well before it approaches 5 minutes, because a lagging replica silently breaches the RPO target with no visible symptom until you need it.

Binary log retention: the thing that actually protects you

Binary logs (binlogs, MySQL's continuous record of committed writes) on the primary have to be retained long enough to survive a replication hiccup, a network blip, a replica restart, without the replica permanently falling behind. If binlogs purge before a lagging replica catches up, the only way to resync is a full reseed of the replica, which defeats the whole point of keeping one warm and ready. Size retention to cover your worst plausible outage on the replication path itself, not just the 5-minute RPO number.

Promotion: the manual, RTO-critical step

Promotion breaks replication and turns the replica into an independent, writable primary. It is deliberate and one-way, there is no automatic rollback once it happens. In practice this means: confirm replica lag is low, stop (or accept losing) writes to the dying primary, promote the replica, update the connection string or DNS record the application uses, resume writes. Every one of those steps is a place the 30-minute budget disappears if it is not scripted and rehearsed ahead of time.

Testing failover without touching production

You cannot rehearse promotion against the real production cross-region replica without destroying it, promotion is one-way. So test with a throwaway stand-in: take a backup-based clone of production, replicate that clone to a second region as a temporary replica, and promote that copy instead, timing the whole runbook end to end. This validates the mechanics and the timing without ever putting the production replica you actually depend on at risk.

Worked example

Primary in one region, cross-region replica in a second region with typical lag of a few seconds under steady load. The primary's region goes fully down at 10:00. From 10:00 to 10:05, alerting confirms the outage and confirms the replica's last recorded lag was under a minute, so the RPO target is met. From 10:05 to 10:15, on-call executes the scripted promotion. From 10:15 to 10:25, the DNS or connection-string cutover propagates and application instances reconnect to the newly promoted primary. From 10:25 to 10:30, a smoke test confirms writes succeed. That spends the full 30-minute budget, and it only works because the promotion step was scripted in advance rather than improvised during the incident.

Trade-offs and pitfalls

Asynchronous cross-region replication means you can never get RPO to zero this way, if a customer's requirement is truly zero data loss across regions, that pushes toward Spanner or a synchronous multi-region architecture, not Cloud SQL cross-region replicas. A common pitfall is rehearsing the runbook only with the person who wrote it, in a calm, well-lit demo, the real RTO clock should assume a paged engineer half-asleep at 3 a.m. following a written script, not the author improvising confidently. A second pitfall: after promotion you no longer have a cross-region replica at all, you are running exposed until a new one is configured, that is a slower-burn risk worth flagging to operations even though it sits outside the 30-minute window.

Direct answer

I would write a design document (also called an RFC, request for comments, a proposal circulated for review) built around problem, goals and non-goals, proposal, cross-team contracts, alternatives, rollout and open questions. I would involve one technical lead per team before writing and name a decision owner, then review in the open while writing. To keep it useful after shipping, I update it to "as built", link the decisions to ADRs (short decision records) and give it an owner.

Structure

1. Header: authors, reviewers per team, status (draft, in review, accepted, shipped), decision owner and date.
2. Context and problem: what hurts today and for whom.
3. Goals and non-goals: non-goals prevent three teams from each assuming the others will cover something.
4. Proposal: the design at the level reviewers need, with one diagram.
5. Contracts between teams: the interface (API or event shape), who owns each side, and who is on call for it. In a three-team feature this is the most valuable section.
6. Alternatives considered: each with why it was rejected.
7. Risks, rollout and rollback: sequencing across teams, what can be launched dark (hidden behind a flag), how to undo.
8. Open questions: each with an owner and due date.

Who I involve and when

• Before writing: a 30-minute conversation with each team's tech lead and product counterpart, then a one-page problem statement they all agree to. Disagreement on the problem is cheaper to find here than in review of a forty-page design.
• While writing: a shared draft with dated comments, a named reviewer per team, and one live review meeting for the hard contract questions. Decisions and their owner are recorded in the document, not in chat.
• A decision method such as DACI (driver, approver, contributors, informed) so one person can close the review.

Worked example

Feature: unified notification preferences across the web app, mobile API and data platform. Goal: one place where a user's choices are stored. Non-goal: redesigning the notification content. Contract: the preference service owns storage; mobile and data teams read through a versioned read API; data receives change events. Open question: what happens for users with conflicting older settings? Owner: mobile lead, due before review two.

After shipping

Change status to shipped, edit the design to match what was actually built, and note the differences. Link ADRs for major decisions, add the owner and a review date, and point the README and runbook (the step-by-step guide for operating the system) to it. A design document that describes intentions rather than the built system misleads the next reader.

Pitfalls

Designing alone then presenting; skipping non-goals; writing the doc for approval rather than for the team that must maintain it.

Direct answer

MECE (pronounced "me-see") stands for mutually exclusive, collectively exhaustive. Mutually exclusive means no item belongs to two branches. Collectively exhaustive means every item belongs to at least one branch. Together: each item has exactly one home. A split is only useful if it is MECE and its branches lead to different actions.

Example: monthly retention fell (illustrative numbers)

Retention is the share of customers at the start of the month who are still customers at the end. Say 1,000 customers started the month; retention fell from 80% (800 kept, 200 lost) to 72% (720 kept, 280 lost), so 80 extra customers left.

A split that looks reasonable but is not MECE

Cut the 1,000 customers into: new users (300), mobile users (500), enterprise customers (150), European customers (200).

• Overlap: Priya joined 10 days ago, uses mobile, is on an enterprise plan and lives in Germany. She sits in all four branches. The counts add to 300 + 500 + 150 + 200 = 1,150, more than the 1,000 customers, which is the quick tell.
• Gap: a two-year-old desktop customer on a small-business plan in the US fits none of the four branches.

The fix: one dimension, one rule

Split by tenure at the start of the month: under 30 days (300), 30 to 179 days (400), 180 days or more (300). Each customer has exactly one start date, so exactly one bucket (exclusive), and 300 + 400 + 300 = 1,000 (exhaustive). Other dimensions such as mobile versus desktop then become a second-level split inside each tenure bucket, never mixed in at the same level.

Tests for any split

1. Sum test: do the branch counts add to the total?
2. One-home test: pick five real items and place each. Two homes means overlap, none means a gap.
3. So-what test: does each branch imply a different action? If not, the split is correct but useless.

How I pick the most useful cut

Four families of splitting dimension:

I choose the dimension where (a) branches differ most in outcome, (b) data exists, (c) branches map to owners, and (d) I can check it quickly. For a retention decline I would start with tenure, because "new-user problem or long-time-user problem" decides which team owns it.

Continuing the example (illustrative, same tenure mix last month): last month 60, 80 and 60 customers were lost in the three tenure buckets (200 in total). This month the losses are 140, 80 and 60 (280 in total). The extra 80 sit entirely in the under-30-days bucket, whose loss rate went from 60/300 = 20% to 140/300 = about 47%, while the other two stayed at 20%. That is the so-what: the problem is onboarding, not long-time customers, so the next split goes inside that bucket.

More partitions

• Signup conversion: never started, started and abandoned, submitted but unverified, completed.
• Onboarding non-completers, with a hypothesis per bucket: (1) never started: the prompt is not being seen; (2) started and stalled: one step is too hard or long; (3) completed but not recorded: a tracking gap undercounts completion; (4) ineligible, such as test or internal accounts: the denominator is polluted. Tie rule: eligibility is checked first, so a stalled internal account lands in bucket 4 only.

Pitfalls

• Mixing dimensions at one level (the 1,150 trap).
• An "Other" bucket that quietly holds half the data.
• Treating MECE as a pass mark: a MECE split nobody can act on is still a bad split.

Direct answer
Speaking up when you notice leadership or business behavior running against a stated principle, or discovering a values-violating practice yourself, is a career-risk-aware judgment call. The strongest answers show that you assessed the risk of speaking up honestly, chose a channel and framing proportionate to the issue, and can describe a concrete outcome, even a partial or mixed one.

Structured elaboration

• Assessing: what made you decide this was worth raising rather than letting go, whether it was a one-off or a pattern, and how material the impact was.
• Channel: who you raised it with first, and why (a direct manager rather than jumping straight to a skip-level or a formal channel, unless the severity warranted it).
• Framing: leading with concrete impact or evidence rather than an accusation, which is what makes an objection hearable rather than confrontational.
• Outcome: what actually changed, or didn't. An honest "it partially worked" or "nothing changed and here is what I did next" is a legitimate and often more credible answer than a perfectly clean resolution.
• The self-discovered variant: if you found the issue yourself, in your own work rather than someone else's, the same shape applies, but the story should show you didn't just quietly fix it and move on. Escalating a self-discovered gap through the proper channel, rather than silently patching it, is the part that demonstrates the competency.

Worked example
While reviewing a data-handling process they had built, a candidate noticed it retained a category of information longer than the stated retention policy required. Rather than quietly deleting the excess and saying nothing, they flagged the specific gap to their manager and the relevant policy owner along with a proposed fix, since a silent fix would have hidden that the gap had existed and might recur elsewhere. The fix was implemented, and the review also surfaced one other process with the same gap that would not have been found otherwise.

Trade-offs and pitfalls
Escalating everything regardless of materiality can read as poor judgment rather than integrity; the strongest answers show calibration about what is worth raising. An outcome of "nothing changed" is realistic and acceptable, but the answer should still show a proportionate attempt, not that you gave up after one try or escalated aggressively without cause. Framing a self-discovered gap as "I caught someone doing something wrong" when the honest version is closer to "I found a gap in a process I owned" overstates the story; the self-discovered version is common and doesn't need to be dressed up as catching someone else.

Situation: In my role as a Solutions Architect I regularly lead architecture discussions, design reviews, and postmortems with engineers, product and sales. These forums must surface trade‑offs, unknowns, and failures—none of which happen if people fear being blamed.

Why psychological safety matters:

• It encourages candid sharing of assumptions, constraints, and risks so designs are realistic.
• It enables early detection of architectural flaws and prevents cascading incidents.
• It turns postmortems into learning opportunities rather than blame sessions, improving long‑term reliability and customer trust.

Three concrete practices I’d introduce:

1. Establish a blameless norm at the start of meetings: explicitly state the goal (find facts, learn, choose best trade‑off). Reinforce with a short checklist (e.g., facts vs. opinions, action owners).
2. Use structured critique: adopt “I like / I wish / What if” rounds during reviews so feedback is specific and constructive, not personal.
3. Run short, rotating facilitation and decision logs: rotate facilitator to distribute power and keep a visible decision log capturing constraints, options considered, and rationale.

How I’d model these behaviors:

• I speak first with humility: share my own uncertainties and recent mistakes to normalize vulnerability.
• I acknowledge good questions and credit contributors publicly (email summary, doc annotations).
• When tensions rise, I call a rapid timeout, refocus on facts, and restate shared goals; then propose a follow‑up spike or experiment if needed.

Result: These practices create an environment where stakeholders raise issues early, decisions are documented with context, and teams move faster with fewer reworks—leading to better solutions and stronger client confidence.

Direct answer
For mission-critical platform components, the build-versus-buy decision should be framed around one question above the others: does building this ourselves create a real, defensible advantage, or are we just recreating a commodity capability at a hidden cost?

Structured elaboration
A usable framework, in order of how the decision typically unfolds:

1. Strategic differentiation: is this component something customers would recognize and value as unique to your product, or is it plumbing every competitor also needs? Commodity infrastructure (message queues, authentication, standard storage) is rarely worth building; genuinely differentiating capability tied to your core value proposition is a stronger build case.
2. Total cost of ownership (TCO), not just sticker price: sum build cost (engineering time to build and to reach production-readiness, not just a prototype), ongoing maintenance cost (on-call burden, upgrade effort, the "second system" cost of keeping it current), and opportunity cost (what that engineering time isn't spent on instead) against the buy option's licensing/usage cost plus integration effort.
3. Integration complexity: how much does the bought option need to be adapted to fit existing systems, and does that adaptation cost erode the supposed time-to-market advantage of buying?
4. Vendor lock-in risk: how hard would it be to migrate away from this vendor later, and does the vendor's roadmap and business stability justify that risk?
5. Support SLAs: does the vendor's contractual support match the reliability bar this "mission-critical" label implies, or would an outage leave you waiting on a support queue for a component your business depends on?
6. Exit costs: what would switching cost, in both directions (leaving the vendor, or later deciding to bring an in-house-built system to a vendor)? A framework that only considers entry cost is incomplete.

Worked example
Applying this to a hypothetical analytics pipeline: differentiation is low (a data pipeline is largely undifferentiated infrastructure); TCO favors buy if a managed service's engineering-week equivalent cost is materially lower than an in-house build once ongoing maintenance is counted, for example, if building and maintaining an in-house pipeline is estimated at 8 engineer-months in year one plus roughly 2 engineer-months per year in ongoing maintenance, against a managed service costing an equivalent of 1.5 engineer-months in integration effort plus a recurring subscription, the buy option is materially cheaper once the ongoing 2-engineer-month annual maintenance burden is added to the build side over even a 2-3 year horizon. Vendor lock-in risk is real but manageable if the pipeline's output format is kept portable (standard file formats, not proprietary query syntax where avoidable). The recommendation: buy, with an explicit note that the decision should be revisited if the pipeline becomes a genuine source of competitive differentiation later (e.g., proprietary real-time processing logic core to the product).

Trade-offs and pitfalls
The most common mistake is comparing sticker price only (annual vendor cost versus a rough build estimate) without including the ongoing maintenance burden on the build side, which systematically understates build's true cost and biases the decision toward building things that should be bought. The opposite mistake is treating "buy" as always safer, ignoring that some genuinely differentiating capabilities are worth the higher risk and cost of building because the alternative is competing on a vendor's undifferentiated offering.