Cloud Architecture Patterns — Interview Q&A
Q: When would you choose CQRS, and when is it overkill?
A: CQRS earns its complexity when read and write workloads genuinely have different scaling needs or shapes — high read volume needing a denormalized, query-optimized view that would be awkward to serve directly from a normalized write schema. It's overkill for a straightforward CRUD service with modest, roughly-balanced read/write load — the cost (two data models, eventual consistency lag, more moving parts) isn't justified without a real asymmetry driving it. A strong answer names the specific asymmetry that would justify it, not just "it's a good pattern for scale" generically.
Q: Walk me through the Saga pattern and how you'd handle a failure partway through.
A: A Saga breaks a distributed transaction into a sequence of local transactions, each publishing an event triggering the next step. If step 3 of 5 fails, compensating transactions run for steps 1 and 2 in reverse order, undoing their effects (canceling a payment that already went through, releasing inventory that was already reserved) — there's no single atomic rollback the way a database transaction has one, so compensation logic has to be explicitly designed per step, ahead of time, not improvised after a failure occurs.
Q: What's the actual difference between Multi-AZ and multi-region, and when do you need the second one?
A: Multi-AZ protects against a single data center-scale failure within one region; multi-region protects against a regional-scale event. Most applications need Multi-AZ as a baseline — it's lower cost and lower complexity, and covers the far more common failure mode. Multi-region is justified by a specific requirement: regulatory data-residency needs across geographies, genuinely global user latency requirements, or a business continuity requirement that explicitly can't tolerate a whole-region outage — not adopted by default "for extra safety" without one of those driving it, given the real cost and conflict-resolution complexity it adds (see Advanced).
Q: How does a Strangler Fig migration actually stay safe in production, beyond just "route some paths to the new service"?
A: The routing layer is necessary but not sufficient — a safe migration also needs shadow traffic comparison before a real cutover (compare the new service's output against the legacy system's for the same real requests, without depending on the new response yet), feature-flag-controlled routing so a percentage shift or full rollback doesn't require a deployment, and an explicit plan for data consistency during the migration window if both systems touch overlapping data. Naming these specifics, not just "route traffic gradually," is what distinguishes real migration experience from a surface-level description of the pattern.
Q: What's the tradeoff between choreography and orchestration in a Saga implementation?
A: Choreography (services react to each other's events independently, no central coordinator) is simpler to start and has less infrastructure, but the overall business process isn't visible anywhere in one place — understanding what happens end-to-end means tracing listeners across every involved service. Orchestration (a central coordinator directs each step) makes the process visible and easier to modify, at the cost of every involved service now depending on that coordinator. Choreography tends to scale better for a small number of simple steps; orchestration becomes clearly better once the saga has several steps or nontrivial compensation logic.
Q: How would you design for partial failure, not just total outage, in a service with several dependencies?
A: Circuit breakers to stop calling a repeatedly-failing dependency and fail fast instead of exhausting resources waiting on it; bulkheads to isolate resource pools per dependency so one struggling dependency can't starve resources shared with healthy ones; and explicit, pre-decided graceful degradation per feature (what does the user actually see if this specific non-critical dependency is down) rather than discovering the real behavior for the first time during an incident. A strong answer treats "designed ahead of time" as the key differentiator from "handled reactively during an outage."
Q: A read replica used for CQRS's read side is lagging behind the write side by several seconds under load — is this a bug?
A: Not inherently — CQRS's read side is eventually consistent by design, and some lag is expected, especially under load. The real question is whether the specific lag amount is acceptable for the specific use case reading from it — a few seconds' staleness might be entirely fine for an analytics dashboard and completely unacceptable for a user immediately viewing their own just-submitted data. This is a case where naming the acceptable-staleness requirement explicitly (a defined SLA, not a vague "as fresh as possible") is the actual engineering decision, and treating all lag as uniformly a "bug" misses that CQRS's whole value proposition includes accepting some lag deliberately.