Architecture Patterns and Tradeoffs Questions

Covers decision making between monolithic and microservice architectures and the broader architecture pattern trade offs that drive those choices. Candidates should explain when a monolith is appropriate versus when to adopt or migrate to microservices, describing technical and organizational criteria such as team size and structure, release cadence, performance and scaling requirements, and business domain boundaries. Expect discussion of trade offs including operational complexity, service independence, deployment velocity, testing and debugging difficulty, data consistency and transactions, latency, cost of infrastructure and monitoring, and security and governance. Evaluate knowledge of Conway law and how team boundaries shape architecture decisions. Be able to articulate migration strategies and concrete approaches such as the strangler pattern, bounded context decomposition, incremental service extraction, API versioning, database migration techniques, deployment and testing strategies to minimize disruption, rollout and rollback plans, and metrics for measuring migration success.

HardSystem Design

80 practiced

Define service-level objectives (SLOs) and error budgets for a set of services that result from splitting a monolith. Explain how to apportion error budgets across downstream services, how teams should act when budgets are exhausted, and how SLO-driven rollback or throttling can be implemented.

Sample Answer

Requirements & goals:- Maintain customer-facing reliability guarantees after splitting a monolith into multiple services.- Define measurable SLOs (latency, availability, correctness) and a global error budget per user-facing transaction.- Allow teams to operate independently with clear operational responsibilities and automated controls (throttling/rollback) when budgets are consumed.

High-level approach:1. Define SLOs and global error budget - For each user journey (e.g., “checkout”), define a golden SLO (e.g., 99.95% success within 300ms) measured end-to-end. - Convert SLO to an error budget: ErrorBudget = 1 - SLO (e.g., 0.05% of requests allowed to fail over measurement window).

2. Apportioning error budgets downstream - Instrument the call graph: identify services participating in the journey and their contribution to failure/latency. - Use weighted allocation: assign each downstream service a share proportional to its impact and risk. Two practical methods: a) Static allocation: assign percentages based on historical blame/criticality (e.g., payment service 40%, inventory 20%). b) Dynamic allocation: compute proportional shares from telemetry (p50/p99 latency contributions, failure rates) and recompute periodically. - Ensure allocations include a reserve buffer (10–20%) for unexpected spikes.

3. Responsibilities & actions when budget is exhausted - Each service owner tracks their local budget and a shared global budget dashboard. - When a service exhausts its local budget: - Immediately enter “mitigation mode”: increase alerts, roll back risky changes, pause non-critical deployments, enable circuit breakers or degrade non-essential features. - If local mitigations don’t restore margin, request consumption from the global reserve with justification and remediation plan. - If global budget approaches exhaustion: - Trigger org-level policies: freeze all non-critical releases, activate throttling tiers, and convene incident review to prioritize fixes.

4. SLO-driven rollback and throttling mechanisms - Automated controls: - Circuit Breakers: open when a downstream’s error rate or latency exceeds thresholds; fallback to cached responses or degraded UX. - Adaptive Throttling: rate-limit new user sessions or non-essential API calls proportional to budget consumption; use tokens per-second per-customer tiers. - Canary Gatekeeping: deployment gating where canaries are allowed only if their projected error impact keeps budgets under threshold. - Automated Rollback: CI/CD pipeline integrates SLO monitors; if canary or production metrics cross SLO thresholds for N minutes, trigger automated rollback. - Enforcement architecture: - Central SLO controller (service) ingests metrics from tracing/metrics (OpenTelemetry/Prometheus), computes budgets, publishes per-service signals (OK/WARN/THROTTLE/ROLLBACK). - Sidecar or gateway enforces throttling and circuit breaking based on controller signals; service meshes (Istio/Linkerd) or API gateways are good enforcement points. - Audit log and runbook link for each enforcement action.

Trade-offs & operational notes:- Static apportionment is simple but can misallocate during code changes; dynamic allocation is more accurate but requires reliable telemetry and stability in calculations.- Favor automated, reversible actions (throttling, circuit-breakers, rollback) over manual interventions for speed.- Invest in observability: trace sampling, per-request latency attribution, and per-transaction success metrics.- Regularly review allocations in postmortems and adjust SLOs and budgets as business priorities evolve.

Outcome:- Clear SLOs preserved end-to-end, predictable operational behavior for teams, automated protective measures to keep customer experience within agreed bounds, and a governance loop to iterate allocations and policies.

HardTechnical

72 practiced

Compare event sourcing and traditional CRUD for an order management system. Analyze the implications for read/write models, replays, storage costs, debugging complexity, auditability, and outline a migration path from a CRUD monolith to an event-sourced microservice design.

Sample Answer

High-level comparison- Model: CRUD persists current state (order row), event sourcing persists immutable events (OrderCreated, ItemAdded, PaymentTaken) and derives state by replaying events.- Read/write separation: CRUD: single read/write model; simple reads, complex writes/transactions. Event sourcing: write model appends events (immutable), reads served by projections (CQRS) optimized per query; eventual consistency between write stream and read models.

Implications- Replays: CRUD has no natural replay; reconstructing history requires audit tables. Event sourcing enables full replay to rebuild projections, migrate schema, or debug flows.- Storage costs: CRUD minimal (current state). Event store grows with every change — higher storage and retention planning, but events are compact and compressible; consider retention/archive strategies.- Debugging complexity: CRUD debugging is straightforward (inspect DB row). Event sourcing requires tooling to inspect event streams and to replay in controlled environments; root-cause often clearer because you see intent, but requires more sophisticated observability.- Auditability & Compliance: Event sourcing provides strong audit trail (who/when/why). CRUD needs additional audit logs to reach parity; event streams are tamper-evident and can be signed/hashed.- Performance: CRUD excels at simple low-latency reads/writes. Event-sourced systems require fast append and well-designed projections for read performance; can scale reads horizontally via projections.

Migration path (CRUD monolith → event-sourced microservice)1. Clarify boundaries: identify Order Bounded Context and events semantics with stakeholders.2. Introduce event bus: add immutable domain events publication alongside CRUD writes (dual-write pattern with outbox to avoid inconsistency).3. Implement read-side projections: build microservice read models subscribed to events; gradually route reads to projections for specific endpoints.4. Incremental cutover: start new features against event-sourced service; use strangler pattern to redirect traffic gradually.5. Backfill and replay: for existing orders, export state -> seed events or generate Synthetic “initial state” events; replay to build projections.6. Data consistency and testing: implement outbox pattern, idempotency, consumer retries; run parallel runs and reconcile results.7. Governance & tooling: deploy event store, retention policies, event versioning strategy, replay tooling, monitoring, and audit dashboards.8. Iterate: migrate bounded contexts incrementally, retire CRUD tables when no reads/writes remain.

Trade-offs & recommendations- Use event sourcing where auditability, complex domain logic, temporal queries, and traceability are primary. For simple CRUD-heavy systems with tight latency/cost constraints, CRUD remains pragmatic.- Mitigate costs with compression, event summarization, and tiered storage; reduce complexity with mature frameworks, robust tooling, and clear event schemas/versioning.

EasyTechnical

89 practiced

Explain the difference between monolithic and microservice architectures. As a Solutions Architect advising a mid-stage startup, list scenarios where a monolith is more appropriate and when microservices are justified. Consider team size, release cadence, operational overhead, time-to-market, and short-term vs long-term maintainability.

MediumSystem Design

98 practiced

You must migrate a monolithic ecommerce checkout to a microservice using incremental extraction and the strangler pattern. The checkout must remain available, order processing must be correct, and you must minimize customer-visible regressions. Sketch a migration plan that covers API gateway routing, dual writes, data sync, idempotency, canarying, and cutover criteria.

Sample Answer

Requirements & constraints:- Zero/low downtime for checkout; preserve order correctness and payment integrity; minimize customer-visible regressions; ability to roll back.

High-level approach: Strangler pattern with incremental feature extraction (cart validation → pricing/tax → payment → order creation). Use API Gateway routing + feature flags to split traffic; implement dual-writes and background data sync; verify via canaries and metrics; cutover when parity proven.

Plan:

1. Design & gating- Define bounded contexts for checkout subdomains and extraction order.- Create API Gateway routes: default to monolith; add route rules by header/cookie/feature-flag to send a % of users to new service.- Introduce a feature-flag service to control percentage and user cohorts.

2. Dual-write and idempotency- For each extracted operation, implement dual-write in the Gateway or orchestration façade: call monolith then new microservice (or vice versa) in the same request path, returning monolith response until cutover.- Ensure idempotency: use request-id/order-id tokens; make operations idempotent at the microservice level (dedupe store + unique constraints), safe retries for network failures.

3. Data sync & consistency- Establish source-of-truth and sync direction per domain. For order data, initial single-writer (monolith) with CDC (Debezium/Kafka) to stream changes to microservice DB.- Use transactional outbox in microservice when it becomes writer.- Reconcile via periodic compare jobs and repair pipelines; surface drift metrics.

4. Canarying & validation- Start with internal canaries and 1% of real traffic. Validate functional parity: correctness of totals, taxes, promotions, latency, failure rates, payment reconciliation.- Monitor business KPIs: checkout success rate, payment declines, cart abandonment, order duplication, downstream fulfillment exceptions.- Run A/B and parallel runs where both systems process and results are compared; block cutover on mismatches above threshold.

5. Cutover criteria & rollback- Quantitative thresholds: <0.1% discrepancies on orders for 48h, error rate within baseline + X, latency within SLA.- Gradual ramp to 100% via feature-flag increments (1% → 5% → 25% → 50% → 100%) with soak periods.- Final cutover: flip routing default to microservice, stop dual-writes, promote microservice DB as primary, disable CDC.- Rollback plan: flip gateway back, resume dual-writes, run reconciliation; preserve schema compat during transitions.

6. Operational concerns- Implement tracing (distributed traces) and logging to compare flows.- Add strong monitoring and alerts, automated rollback trigger on business KPI breaches.- Run chaos tests in pre-prod for partial failures, payment gateway outages.- Security: ensure PCI scope; tokenization consistent; secrets and key management.

Trade-offs:- Dual-writes increase write latency; mitigate by async where safe.- CDC adds complexity but minimizes downtime.

This plan ensures incremental risk reduction, continuous validation, and clear cutover/rollback gates so checkout remains available and order correctness is preserved.

MediumTechnical

104 practiced

Outline the factors you would include when estimating operational cost differences between a monolith and a microservices architecture. Include compute, network, monitoring, storage, engineering effort, and platform overheads, and recommend tactics to control ongoing costs during and after migration.

Sample Answer

Start by clarifying scope (expected scale, traffic patterns, SLA, deployment frequency) because cost drivers depend on load, number of services, and ops model (managed vs self‑hosted).

Key factors to include and how they change from monolith → microservices:

- Compute: more JVMs/containers → higher baseline vCPU/RAM usage and more autoscaling events. Account for instance overhead, bin-packing inefficiency, and cold-starts for serverless.- Network: inter‑service east‑west traffic increases; factor per-GB transfer, load balancers, service mesh sidecar overhead and latency-induced scaling.- Monitoring & Observability: per-service metrics/trace/log volume explodes (cardinality, retention). Include costs for ingestion, storage, sampling, APM traces, and dashboards.- Storage: more databases or schemas, possible duplication, higher metadata and backup costs; consider per-request storage egress and read/write patterns.- Engineering effort: migration planning, API contracts, testing, CI/CD pipelines, increased operational playbooks, SRE/handoffs, debugging time. Include ramp-up productivity dip.- Platform overheads: container orchestration (k8s control plane), service mesh, CI runners, deployment orchestration, image registries, secrets management.

Tactics to control costs:- During migration: adopt strangler pattern to incrementally split high-value domains; measure per-service cost early; set budgets/alerts per namespace; prioritize services with clear scaling or resilience benefits.- Right-sizing & autoscaling: use vertical/horizontal autoscaling with resource requests/limits, use burstable instance families, and reserved/spot instances where appropriate.- Reduce observability volume: sample traces, lower metric cardinality, use rollups and shorter retention for high‑frequency metrics; only persist logs needed for compliance.- Network optimization: collocate latency-sensitive services, use VPC endpoints, compress payloads, cache heavily used responses.- Platform efficiencies: standardize base images, use multi-tenant runtime where safe, adopt GitOps to reduce pipeline costs, consolidate shared infra (APIs/gateways).- Ongoing governance: chargeback/showback per team, enforce quotas, periodic cost reviews, automated cleanup of unused resources, and SLO-driven alerting to avoid overprovisioning.

Present the model as a spreadsheet that projects monthly cost by component (compute, network, monitoring, storage, infra, engineering) under conservative/likely/aggressive scenarios and iterate with real telemetry after cutover.

Unlock Full Question Bank

Get access to hundreds of Architecture Patterns and Tradeoffs interview questions and detailed answers.

Join thousands of developers preparing for their dream job.