Senior Solutions Architect Interview Preparation Guide - FAANG Standards

Direct answer

Service-model choice does not change whether you can meet an EU data-residency requirement; it changes how much of the compliance burden is technical, something you configure and verify yourself, versus contractual, something you have to get in writing and trust. That split tracks the shared-responsibility boundary that governs every service model: IaaS gives you the most levers to pull yourself, SaaS gives you the fewest and pushes the burden toward contract terms.

Controls by model

Worked example

A company running an EU customer database on IaaS provisions its own virtual machines and database engine in an EU region and configures backup jobs to write only to EU storage, verifiable by inspecting their own infrastructure. On PaaS, they pick a managed database's EU region, but must additionally check the vendor's documentation for whether that service's automated backups, diagnostic logs, or support-access tooling are also EU-scoped, since providers have historically kept some metadata in a home region by default. On SaaS, for example a customer-support ticketing product, residency depends entirely on whether the vendor sells an EU-residency tier; if it does not, the technical option may not exist at all, and the choice becomes either avoiding that vendor for EU personal data or accepting a contractual transfer mechanism with legal sign-off.

Trade-offs and pitfalls

The biggest pitfall is assuming "I picked the EU region in the console" fully discharges the requirement above IaaS: managed-service metadata, provider support access, and third-party sub-processors can each independently violate residency even when the primary data store is correctly pinned. On SaaS specifically, pin down what the underlying regulation actually requires, for example the EU's General Data Protection Regulation (GDPR) if that is the driver, since "data must remain in the EU" and "a transfer of personal data outside the EU needs a valid transfer mechanism" are two different, commonly conflated obligations. Treating a residency requirement as absolute when the real rule permits a properly documented transfer mechanism can lead you to reject an otherwise workable vendor for no real compliance benefit.

Bottom line

With only a couple of overlapping hours a day, the design has to be async-first by default, saving the small live window for the handful of things that genuinely need real-time back-and-forth, and giving the new hire a real, well-bounded task early enough that their progress doesn't depend on the US team being awake.

Before the overlap hours matter

Days 1 to 5, front-load a written orientation packet, architecture overview, how the team actually works, where decisions get recorded, so they read it before the first live call and the overlap time gets spent on questions, not a lecture they could've absorbed on their own schedule.

Using the overlap window deliberately

Reserve it for two or three things that truly need synchronous time: pairing on their local dev environment setup in week one, and one live intro to their buddy, so there's a real human connection early, not just written access. Everything else, status updates, routine questions, defaults to async.

Async practices

Written design docs with async comments instead of live design reviews, recorded walkthroughs of the codebase instead of live tours, and a shared decisions log so "why is this built this way" has a written answer instead of requiring a live person in an inconvenient time zone.

Shipping something within 30 days

Scope a real, well-bounded first ticket in week one, something with a clear owner and a clear definition of done, like adding test coverage to a module the team already understands well, so they can make visible progress without being blocked on same-timezone humans.

Worked example

A new hire in Singapore joining a team based in US Pacific time has roughly a 6 to 8am Pacific, or 9 to 11pm Singapore, overlap window. That window gets used for the first week's environment-setup pairing and the buddy introduction, and nothing else, after that the default is async unless they're genuinely stuck.

Trade-offs and pitfalls

Going purely async from day one can feel isolating, some real-time human contact matters for belonging, not just logistics. The other common failure is assuming documentation exists when it's actually tribal knowledge that lives in people's heads, which is exactly what the buddy relationship should be surfacing and turning into writing as it's discovered.

Direct answer

Change data capture (CDC), dual-write, and event-sourcing are three different ways to keep a legacy database and a new datastore consistent during a migration, and they trade off implementation complexity against how much you can trust the result. Dual-write is simplest to build but easiest to get subtly wrong; CDC is more reliable because it reads from a single source of truth rather than writing to two places; event-sourcing is the most invasive to adopt but gives you the strongest guarantees, because both sides derive from the same append-only log rather than one side deriving from the other.

Structured elaboration

• Dual-write: application code writes to both the legacy database and the new datastore in the same request. It's the fastest to implement, but the two writes are not atomic across two different systems unless you add real machinery (a distributed transaction, or a two-phase commit) to make them so, and most teams don't. That means a crash, a timeout, or a partial failure between the two writes leaves them silently inconsistent, drift that's invisible until something downstream (a reconciliation job, a customer complaint) surfaces it, often long after the divergence happened.
• CDC: instead of the application writing to two places, a CDC process reads the legacy database's own change log (its write-ahead log or binlog) and replays those changes into the new datastore asynchronously. This is more reliable than dual-write because there's exactly one write path (the legacy database), and the new datastore is always a downstream consumer of a durable, ordered log of what actually happened, not a second write your application might fail to complete. The cost is operational complexity: you need a CDC pipeline, and you're accepting eventual consistency, since the new side lags the legacy side by however long propagation takes.
• Event-sourcing: instead of either side being the "real" data store, the system of record becomes an append-only log of events, and both the legacy view and the new view are projections derived from that same log. This gives the strongest consistency guarantee, because there's no possibility of the two sides disagreeing about what happened, only about how far each has caught up, but adopting it usually means restructuring how the legacy system itself writes data, which is a much bigger lift than the other two options and often not realistic for a legacy system you're trying to move away from rather than invest further in.

Idempotency matters across all three: CDC pipelines and event consumers need to handle receiving the same change twice (from a retry, a pipeline restart) without double-applying it, usually by keying operations on a unique change identifier and making the apply operation itself idempotent (an upsert rather than an insert).

For migrating background jobs and batch processes specifically, the same principles apply but the risk shifts: a batch job re-run after a partial failure needs to be safe to simply run again (idempotent), and jobs that process data in a fixed order need explicit ordering guarantees carried through the migration, or backpressure handling if the new platform processes at a different rate than the old one, since a batch job silently falling behind is a common way migrations quietly degrade downstream freshness without an obvious failure.

Worked example

Migrating customer records from a legacy relational database to a new microservice's datastore:

• The team initially considers dual-write, but recognizes that a write succeeding on the legacy side and failing on the new side (a timeout, a schema validation error the legacy side doesn't enforce) would silently drift the two systems apart, with no built-in way to detect it.
• They choose CDC instead: a pipeline reads the legacy database's change log and applies each change to the new datastore, keyed by a monotonically increasing change sequence number so a re-delivered change (from a pipeline restart) is a safe no-op rather than a duplicate.
• They add a reconciliation job that periodically compares row counts and checksums between the two sides, specifically to catch the kind of divergence that would have been invisible under dual-write and remains a small residual risk even under CDC, since propagation lag means the two sides are never instantaneously identical, only eventually so.
• For a nightly batch job that also touches these records, they make sure it's idempotent (re-running it produces the same end state, not duplicated effects) so a mid-run failure during the transition period is safe to simply retry.

Trade-offs and pitfalls

The recurring pitfall across all three approaches is treating "the two sides matched in testing" as proof they'll stay matched in production; real production traffic has failure modes (partial network failures, unexpected data shapes, load-related timing) that staging rarely reproduces, which is why an ongoing reconciliation and drift-detection process, not just a one-time migration validation, is what actually gives you confidence during an extended migration window.

Direct answer. I translate each business goal into the risks that could stop it, then the capabilities (things the organisation must be able to do, stated as outcomes) needed to reduce those risks, then initiatives, and I sequence them by dependency under the flat budget. A roadmap becomes a tool list when lines name products; each line here names a goal, a risk, one accountable owner (others may support) and a measurable outcome, with the tool as an implementation detail.

A line before and after. Tool-list line: "Deploy a cloud security posture tool, Q1." Outcome line: "Migrate to cloud: no new cloud account is created without baseline guardrails (automatic rules that block unsafe setups such as publicly open storage). Owner: cloud platform lead. Measure: 100% of new accounts created with guardrails from Q2, and zero publicly exposed storage buckets found in the monthly scan." The tool is chosen later, as an implementation detail.

Goals, risks, capabilities (example goals: cloud migration, a payments launch, a regulatory requirement)

Budget under flat funding (illustrative $4.0M). 60% run costs (the ongoing cost of operating what already exists: licences and the staff who run it) = $2.4M, 30% goal-driven work = $1.2M, 10% reserve = $0.4M. New work is paid for by stopping something, using a stop list agreed in advance (for example retiring a duplicate scanner whose findings nobody reads).

Test to avoid a tool list. For every line ask: which goal, which risk, what changes for a user, how will we measure it? If it fails, remove it.

Stakeholders. Map: payments and platform leads (affected most; co-design), general counsel and compliance (shape the regulatory line), finance (budget), engineering and product leadership (who must adopt). Present on one page, quarter by quarter, in business terms, with decisions needed from each stakeholder and the trade-off if the date moves.

Pitfalls. Sequencing by vendor availability, no stop list, and a roadmap that never changes. Review quarterly and tell leadership what moved and why.

Situation: Three days before submission a client adds a country-specific data-residency requirement.

Immediate steps (first 24 hours)

• Triage: confirm exact requirement scope (which data, retention, processing vs. storage) with account lead/PM and client.
• Risk/feasibility quick audit: check current architecture, cloud region availability, legal/compliance, and any existing in-country partners.
• Convene a rapid cross-functional huddle: Sales (AE), Legal/Compliance, Cloud/Infra engineering, Security, Delivery lead, and Procurement.

Assess & design

• Map affected data flows and components; identify what must be hosted in-country vs. can be pseudonymized/aggregated.
• Propose 2–3 options: (A) native regional deployment (new cloud region/account), (B) hybrid (local storage + central processing with encrypted transfer), (C) partner/local datacenter or managed hosting.
• For each option list constraints, security controls (encryption at rest/in transit, key management), and migration approach.

Estimate cost & timeline

• Provide ballpark estimates: infra provisioning, licensing, engineering effort, legal reviews, and SLA impacts. Break into fixed vs. recurring costs and estimate timeline for MVP vs. full compliance (e.g., 1–4 weeks infra + 2–8 weeks validation, depending on option).

What to present to Sales

• A concise decision memo with: clarified requirement, proposed options (with pros/cons), cost/time ranges, risk level, dependencies, recommended option, and ask (e.g., budget/time extension or acceptance of mitigations).
• Include impact on contract terms and a suggested change request text.

Documentation to produce

• Updated architecture diagram highlighting in-country components and data flows.
• Short compliance checklist and assumptions.
• Migration/implementation runbook outline and roll-back plan.
• Risk register and residual risk mitigation.
• Estimated BOM and timeline Gantt.

Follow-up

• Agree next steps, sign-offs and a communication plan with client and Sales; capture approval for chosen option before updating the formal proposal.

At 100M to 1B events/day with hundreds to thousands of concurrent BI/ad-hoc users, the design has to separate three concerns that are often conflated: where raw data lands, what serves fast interactive queries, and how you keep cost proportional to actual usage rather than peak capacity.

Architecture

flowchart LR
    A[Event sources] --> B[Ingestion: Kafka/Kinesis]
    B --> C[Raw storage: object storage, partitioned by date]
    C --> D[Transform: dbt/Spark]
    D --> E[Curated warehouse/lakehouse tables]
    E --> F[Materialized aggregates + cache]
    F --> G[BI / ad-hoc query layer]
    E --> H[Ad-hoc query engine: Presto/Trino]
    I[Orchestrator] -.-> B
    I -.-> D
    J[Monitoring + catalog] -.-> C
    J -.-> E

Storage layer: a lakehouse (open table format like Apache Iceberg or Delta Lake over object storage) is the right default at this scale, because it gives you cheap raw retention alongside ACID-safe (atomicity, consistency, isolation, durability) curated tables without maintaining two separate copies of the data for BI versus ad-hoc/ML use.
Compute/query engine: split by workload. Scheduled transformation and large ad-hoc scans go through Spark or Presto/Trino; the bulk of BI dashboard traffic should hit pre-aggregated, materialized tables rather than scanning raw fact tables live, since hundreds of concurrent dashboard refreshes against raw data will not hold predictable latency.
Caching and materialization: build daily or hourly materialized aggregates for the metrics that dashboards actually chart repeatedly (this is the single highest-leverage latency and cost lever at this scale), and put a query-result cache in front of the BI layer for identical repeated queries.
Workload isolation: give ad-hoc/exploratory queries a separate compute pool (a separate warehouse, or a separate Presto/Trino cluster) from the scheduled BI dashboard refreshes, so one analyst's expensive ad-hoc query cannot degrade dashboard latency for everyone else.
Cost controls: partition and cluster raw and curated tables on the columns dashboards actually filter on (date, region, product), enforce query timeouts and byte-scanned quotas on the ad-hoc pool, and autoscale compute down aggressively outside business hours.

Multi-region extension

If the platform must serve low-latency dashboards across regions, replicate the curated (not raw) layer to a read replica or regional cache near each user population, route BI queries to the nearest region, and keep a single source-of-truth region for raw ingestion and transformation to avoid multi-writer consistency problems. Accept eventual consistency between regions (typically a few minutes of replication lag) rather than trying to build synchronous cross-region writes, which would tank both latency and availability for a marginal freshness benefit.

Worked example

If a single dashboard metric (say, daily revenue by region) is queried 5,000 times a day by different analysts but the underlying data only changes once a day after the nightly ETL (extract, transform, load) run, materializing that one aggregate turns 5,000 potentially-expensive raw scans into 5,000 cheap reads of a small precomputed table, which is the difference between a system that needs constant capacity tuning and one that comfortably serves thousands of users on modest compute.

Trade-offs and pitfalls

The most common failure at this scale is letting BI dashboards query raw or lightly-aggregated fact tables directly "because it's simpler," which works in a demo with ten users and falls over once real concurrency and real data volume both show up. The second is over-isolating workloads into so many separate compute pools that operational overhead (monitoring, cost allocation, capacity tuning per pool) exceeds the benefit; two or three pools (ETL, BI, ad-hoc) is usually enough.

Baseline math (everything kept in requests per second, RPS)

Current: 50,000 RPS at 60% CPU
Capacity at 100% CPU (today's fleet) = 50,000 / 0.60 = 83,333 RPS

Utilization at 60 percent while serving 50,000 RPS tells us the fleet's real ceiling today is about 83,333 RPS if it ran flat out, which we never actually want to do.

Baseline in 6 months with 30% growth = 50,000 x 1.30 = 65,000 RPS
Capacity needed to hold 60% target utilization = 65,000 / 0.60 = 108,333 RPS

Holding the same 60 percent target utilization at the grown baseline needs about 108,333 RPS of capacity, roughly 30 percent more fleet than today, which makes sense: if the target utilization does not change, fleet size scales linearly with traffic.

Flash peak on top of the grown baseline = 65,000 x 5 = 325,000 RPS
Capacity to hold 60% utilization at that peak = 325,000 / 0.60 = 541,667 RPS

That is about 6.5x today's compute footprint (541,667 / 83,333). Holding that permanently, year-round, for an "occasional" spike is not economical, so the plan treats it as an elastic ceiling, not a standing fleet.

Horizontal vs vertical scaling

Horizontal (more stateless instances) is the primary lever: it scales close to linearly and improves fault tolerance. Vertical scaling (bigger instances) is reserved for anything that cannot be sharded easily, such as a single-writer database, and even there it is a stopgap since it has a hard ceiling and usually needs a resize/restart.

Autoscaling policy and buffer sizing

Run target-tracking autoscaling around the same 60 percent utilization target the fleet runs at today, with the maximum instance count set high enough to cover the 5x flash case (the 541,667 RPS figure above). If flash events are known in advance (an announced sale), add scheduled pre-warming ahead of the event, because reactive-only autoscaling cannot launch, boot, and warm 6.5x the fleet inside a sudden spike without some queueing and latency degradation first.

Peak concurrency modeling

Use Little's Law (a queueing-theory result: average concurrent requests in flight equals throughput multiplied by average request latency) to size not just instance counts but connection pools and downstream (database, cache) query rates at each of the three traffic levels above, since the DB or cache can become the real ceiling even when the app tier autoscales fine.

Validating with load testing

Run a ramp test to the 6-month baseline (65,000 RPS) to confirm steady-state headroom holds, and a separate spike test that ramps from baseline to the 325,000 RPS flash level over a realistic ramp time to confirm the autoscaler (or pre-warmed buffer) keeps p95 latency inside SLO during the spike, not just after it settles.

Presenting cost vs headroom to stakeholders

Frame it as a curve, not a single number: holding permanent capacity for the 5x case year-round costs roughly 6.5x today's compute bill for a scenario that only happens occasionally, versus an autoscaling-plus-pre-warm approach that costs close to the 30 percent growth-driven increase most of the time, with a stated, honestly communicated risk window (the minutes it takes to scale out) for any flash event that arrives without advance notice.

Direct answer

Expect a director managing three to five team leads or senior individual contributors directly, a total team of roughly 15 to 30 people split into several smaller pods (small, semi-autonomous sub-teams, each owning a specific area of the product) each with its own lead, and a mission written as a narrower slice of company strategy the director is accountable for, not the company's mission as a whole. Those two numbers are linked rather than independent guesses: a line manager's practical span is roughly five to eight direct reports, so three to four pods at that size is exactly what puts the total in the 15 to 30 range, and the director's own span sits at the low end of that same band because each of their reports carries a whole pod's worth of context rather than one person's.

Structured elaboration

• Typical roles and titles: Director, then three to five Engineering Managers or Staff/Senior individual contributors as pod leads, then each pod's own engineers (a mix of junior through senior), often with an embedded or partner product manager per pod and sometimes a shared designer or data scientist across pods.
• On-call ownership (on-call: a rotation where a specific person is responsible for responding to production issues outside normal hours): at a mid-stage company this is usually owned at the pod level, each pod is responsible for the on-call rotation for the systems it built, with the director accountable for the aggregate reliability picture across pods, not for running the rotation itself.
• Connecting mission to business objectives: a director's mission is usually one level of translation down from a company-level goal. A company objective like "grow enterprise revenue" becomes a team mission like "reduce enterprise onboarding time," something concrete enough that individual project work can be traced back to it directly.
• How to sanity-check your own numbers out loud: multiply, do not guess. Pods of five to eight, times the three to four pods one director can carry, gives 15 to 30 people. If the size you quote and the structure you describe do not multiply out to each other, an interviewer who does that arithmetic in their head has just found the seam in your answer.

Worked example

A Platform Engineering org at a roughly 600-person B2B software company, reporting to a Director of Platform Engineering. Composition: three pods, "Provisioning," "Observability," and "Cost and Capacity," of five to seven engineers each, so roughly 18 engineers plus the three pod leads plus the director, about 22 people in total, which lands in the middle of the 15 to 30 range above. Each pod runs its own on-call rotation, with the director reviewing an aggregate reliability report across pods monthly. Mission: the company's stated goal is to support fast customer growth without proportional infrastructure cost growth, which becomes the Platform org's mission of cutting provisioning time per new customer environment while holding infra cost per customer roughly flat, a line that's specific enough you could plausibly hear it stated in an actual interview.

Trade-offs and pitfalls

The most common error is assuming a flat structure, everyone reporting straight to the director. Once one person's direct reports pass the top of that five-to-eight span, roughly eight to ten people, it stops scaling and a middle layer of leads appears; leaving that layer out of your answer reads as inexperienced. The second most common error is quoting a headcount range and a pod structure that quietly contradict each other, which is easy to do because each half sounds reasonable on its own. It's also worth not just restating the org chart on its own, connecting the composition back to the mission is the part an interviewer is actually listening for.

Direct Answer

A saga coordinates a business transaction that spans multiple services by breaking it into a sequence of local transactions. Each service commits its own step immediately with no cross-service lock held, and if a later step fails, the saga undoes the steps that already succeeded by running a compensating action for each one, in reverse order. This trades strict, all-or-nothing atomicity for eventual, recoverable consistency and loose coupling between services.

Choreography vs. Orchestration

• Orchestration: a central coordinator issues each step as a command to the relevant service and decides, based on that service's response, what to do next, including which compensations to trigger if something fails. The whole workflow lives in one place, which makes it easier to see, test, and reason about end to end.
• Choreography: there is no central coordinator; each service publishes an event when it finishes its local step, and whichever service is subscribed to that event reacts by doing its own step and publishing its own event in turn. This avoids coupling every service to a central coordinator's command contract, but it scatters the workflow logic across services, so understanding or changing the whole sequence means tracing through several services' event subscriptions instead of reading one place.

Worked Trace: Order Fulfillment When Shipment Fails (Orchestration Style)

Order O123, three steps: reserve inventory, charge payment, schedule shipment.

1. Orchestrator sends ReserveInventory(O123, sku=42, qty=1) to Inventory. Inventory reserves the unit and replies Reserved.
2. Orchestrator sends ChargePayment(O123, $50) to Payment. Payment captures the charge and replies Charged.
3. Orchestrator sends ScheduleShipment(O123) to Shipping. Shipping tries to allocate a carrier slot and replies Failed: no carrier capacity.
4. The orchestrator now runs compensations in reverse order. It sends RefundPayment(O123, $50) to Payment, undoing step 2. Payment replies Refunded.
5. It sends ReleaseReservation(O123, sku=42, qty=1) to Inventory, undoing step 1. Inventory replies Released.
6. The orchestrator marks order O123 as Failed and notifies the customer.

The same sequence in choreography looks like this instead: Inventory reserves and emits InventoryReserved(O123). Payment, subscribed to that event, charges and emits PaymentCharged(O123). Shipping, subscribed to PaymentCharged, tries to schedule and, on failure, emits ShipmentFailed(O123). Both Payment and Inventory are subscribed to ShipmentFailed: Payment independently issues its own refund and emits PaymentRefunded(O123), and Inventory independently releases its reservation and emits ReservationReleased(O123). No single component ever holds the full picture of the workflow; each service only knows what to do when it sees an event it's subscribed to.

Trade-offs and Pitfalls

• Every forward step and every compensating action has to tolerate being retried, since at-least-once delivery means ChargePayment could be delivered twice; this is a system-property requirement on the saga's steps, a separate concern from how an external API exposes idempotency to its own callers.
• The saga's state, meaning which steps have completed and which compensations are pending, needs to be durably persisted, whether by a central orchestrator or by each participant in a choreography, so that a crash and restart can resume the saga correctly instead of leaving it stuck partway.
• Not every action has a true inverse. Compensating a shipment step after the package has physically left the warehouse can't undo the physical fact, only correct the system's record and possibly trigger a real-world return process; a senior design puts the hardest-to-compensate steps as late as possible in the sequence.
• Choose a saga when the steps naturally live in separate services or databases and each one can be given a real, working compensating action. Reach for a real distributed transaction only when an intermediate, partially-applied state genuinely cannot be tolerated and you can afford a synchronous locking protocol across every participant, which a saga specifically avoids.

Summary recommendation: Buy the managed SaaS unless you require heavy custom analytics, proprietary IP capture, or strict data residency/compliance — SaaS delivers ~3x lower 3-year TCO, much faster time-to-value, and lower operational risk.

3-year TCO (high-level)

Assumptions used:

• 3 engineers @ $150k/yr; 1 SRE @ $175k/yr
• Infra (build) $10k/month for 2 years
• SaaS license $12k/month
• 3 months integration effort (engineers)

Build (in-house)

• Engineers (3) over 3 yrs: 3 * $150k * 3 = $1,350,000
• SRE over 3 yrs: $175k * 3 = $525,000
• Infra: $10k/mo * 24 months + conservative $5k/mo in year 3 = $240,000 + $60,000 = $300,000
• Overhead (security, monitoring, backup tools, training, 10% of labor): ≈ $187,500
  Total (3 yrs) ≈ $2,362,500

Buy (SaaS)

• SaaS license: $12k/mo * 36 = $432,000
• Integration effort: 3 engineers * ($150k/12) * 3 months = $112,500 (one-time)
• SRE/ops (vendor integration, runbooks, 25% FTE): 0.25 * $175k * 3 = $131,250
• Contract/legal/vendor mgmt & contingency (~10%): ≈ $67,725
  Total (3 yrs) ≈ $743,475

Net difference: Build ≈ $2.36M vs Buy ≈ $0.74M → ~ $1.62M savings favoring SaaS over 3 years.

Hidden costs to include before final decision

• Build: ongoing feature roadmap dev, long-term maintenance, technical debt, security/compliance tooling, backups and DR testing, hiring/replacement risk, performance scaling, SLA obligations, monitoring/alert noise, audit costs.
• Buy: data egress and integration costs, limited customization, vendor lock-in and exit/migration costs, per-feature or per-seat add-ons, SLA limitations and support escalation, compliance/gov risks, shadow IT if teams bypass integration.
• Both: training, change management, analytics governance, data lineage, and observability costs.

Recommendation & rationale

• Default: Choose SaaS now if your needs match standard analytics, you prioritize speed-to-value, and want to avoid recruiting/ops burden. It’s materially cheaper and reduces operational risk.
• Build only if: you require unique/custom analytics pipelines that are core IP, have predictable scale where marginal cost favors in-house, or strict regulatory constraints prevent SaaS usage.
  Next steps if buying: run a 3-month pilot, negotiate SLAs and exit terms, validate data portability and egress costs, define runbook and observability requirements, and include a 12–18 month review to reassess cost/performance.