Solution Architecture and Design Questions

Designing and architecting end to end technical solutions for enterprise and complex systems, covering both the methodology for approaching architecture problems and the practical component level design work. Candidates should demonstrate a repeatable structured approach to elicit and document functional and non functional requirements, identify constraints and stakeholders, evaluate and compare multiple architectural options, and justify technology choices. They should produce high level and component level designs that show major services, presentation layers, application tiers, data layers, data flows, storage strategies, application programming interfaces, integration points with external and third party systems, and data movement and transformation. Strong responses explicitly address quality attributes such as scalability, performance, availability, fault tolerance, reliability, consistency and security as well as compliance and data protection concerns. Operational concerns must be covered including deployment topology, multi region and hybrid cloud strategies, monitoring and observability, logging, capacity planning, backup and disaster recovery, deployment and release strategies, maintenance, and operational run books. Candidates should discuss communication patterns including synchronous remote procedure calls and asynchronous messaging, storage trade offs between relational and non relational datastores and data warehouses, failure modes and mitigation strategies, incremental evolution and migration paths, and cost and feasibility constraints. Interviewers assess the ability to present clear diagrams, explain interactions and failure modes, reason about trade offs, and justify design decisions against requirements and constraints.

EasyTechnical

17 practiced

A client asks how to decompose a large monolithic ERP into microservices. Explain a practical, incremental decomposition strategy. Include criteria for identifying service boundaries, patterns to avoid (e.g., chatty services), and how you would handle shared libraries, cross-cutting concerns, and data separation.

Sample Answer

Start by aligning technical work to business capabilities. I recommend an incremental, risk-minimizing approach using Domain-Driven Design + the Strangler Pattern.

Stepwise strategy- Discover: run workshops to identify bounded contexts (sales, finance, inventory, manufacturing) and map business flows, change frequency, SLAs and team ownership.- Prioritize: pick a low-risk, high-value context (e.g., invoicing) as a pilot that’s isolated and has clear inputs/outputs.- Strangle incrementally: route parts of traffic from the monolith to the new service behind an API gateway, iterate until the monolith path can be retired.- Repeat by business priority, adding observability, automated tests, and rollback plans.

Criteria for service boundaries- Business capability / bounded context- High cohesion, low coupling- Independent deployability and ownership- Different scaling / availability needs- Different change velocity or compliance requirements

Patterns to avoid- Chatty fine-grained RPCs—prefer coarse-grained APIs or bulk endpoints- Shared DB tables across services (creates coupling)- Premature extraction of highly coupled functionality

Handling shared libraries and cross-cutting concerns- Keep platform-level concerns as infra services: API Gateway for auth/rate-limiting, identity service for authn/z, logging/metrics collector, config service.- Shared libraries only for non-business utilities (serialization, common SDKs) and publish versioned packages; prefer backward-compatible APIs.- Use service mesh (or sidecars) and centralized observability instead of embedding concerns in business services.

Data separation and consistency- Database-per-service for independence. For read-heavy cross-domain needs use materialized views or CQRS with event-sourcing.- Use asynchronous integration (events) and idempotent consumers to avoid tight coupling; use sagas or orchestration for distributed transactions.- Anti-corruption layers when integrating legacy modules to translate models and protect new services from monolith assumptions.

Operational practices- Automated CI/CD, contract testing, feature flags for traffic migration, robust monitoring and alerting.- Governance: API versioning policy, clear ownership, and an incremental roadmap.

Outcome: low-risk, business-aligned decomposition that maintains stability while enabling independent scaling and faster delivery.

HardSystem Design

23 practiced

Design a globally distributed e-commerce checkout system that must provide low-latency checkout for users worldwide while ensuring inventory correctness and payment integrity. List components, data partitioning choices, payment processing flow, techniques to reduce checkout latency, and how you would handle inventory conflicts and fraud prevention.

Sample Answer

Requirements & constraints:- Global low-latency checkout (≤100–200 ms perceived),- Strong inventory correctness (no oversell, eventual/strong consistency trade-offs per SKU),- Payment integrity and fraud prevention, multi-region compliance (PCI-DSS), high availability.

High-level architecture:- Edge: CDN + Global LB (Anycast) → Regional API Gateway- Regional Checkout Service (stateless) + Cart Service (session store)- Inventory Service with multi-master replication OR partitioned primary-per-region with global coordinator- Order Service (event-sourced) + Distributed Saga Coordinator- Payment Gateway Adapter (regional PCI enclave + tokenization)- Global Inventory Coordinator (lightweight), CQRS read models, async processors- Datastores: regional primary DBs (for latency), global replicated read-store (Elasticsearch / Redis for reads)- Observability: distributed tracing, real-time metrics, audit logs

Data partitioning:- Partition inventory by SKU hash and geography (hot SKUs replicated more widely). Use primary-per-partition leader chosen by region affinity (owner region for SKU) to ensure strong correctness for that SKU; other regions use async replica + local reservations.

Payment processing flow:1. Customer submits checkout to regional API.2. Reserve inventory locally (short-lived local hold) via Inventory Service; write to local DB + publish "reserved" event.3. Start distributed Saga: - Authorize payment via Payment Adapter in regional PCI enclave (tokenize card; use 3DS where required). - On auth success, commit inventory (decrement leader partition) via Global Inventory Coordinator if this region is not owner — use a fast two-phase commit/optimistic commit with idempotency tokens. - Create Order canonical record; emit "order-confirmed" event.4. Capture payment after confirm (or authorize-and-capture per business rules).5. If any step fails, compensate: release reservation, void auth, notify user.

Techniques to reduce latency:- Keep checkout path local: local API + cache product/price/availability read models (stale-read with freshness bounds).- Quick local reservation (soft hold) to hide cross-region commit latencies.- Pre-tokenize payments and use local PCI enclaves to avoid cross-region round trips.- Client-side optimizations: asynchronous payment verification, optimistic UI, background inventory finalization.- Use CDN + edge compute for address validation, tax estimation.

Handling inventory conflicts:- Use two-tier reservation: local soft holds (fast, TTL-based) + authoritative commit on partition leader.- Conflict resolution via last-writer-wins with idempotent operations and monotonic sequence numbers per SKU lead.- If concurrent commit conflict occurs, use compensation (notify customer and attempt partial fulfillment or alternate SKU), prioritize fairness by reservation timestamp.

Fraud prevention:- Real-time fraud scoring at edge + regional risk service (ML model + rules).- Velocity checks, device fingerprinting, geo/IP anomaly, payment method risk profile.- Risk gates: require 3DS, manual review queue, increase verification for flagged orders.- Use tokenization, PCI scope isolation, merchant risk dashboards, blacklists/whitelists, and post-transaction monitoring with chargeback workflows.

Trade-offs:- Strong global consistency increases latency; using local reservations + authoritative commit balances UX and correctness.- Multi-master replication is complex; prefer partitioned leaders for correctness and simpler conflict handling.

Operational concerns:- Chaos testing for region failover, runbooks for split-brain, RPO/RTO SLAs, regular compliance audits, monitoring for inventory divergence and fraud trends.

EasyTechnical

21 practiced

Describe common cache patterns (in-memory cache, CDN edge cache, distributed cache, write-through, write-back, read-through) and where each is appropriate in a typical web application. Explain common invalidation strategies and the cache coherency issues you must consider.

Sample Answer

Common cache patterns and when to use them:

- In-memory cache (local process, e.g., app memory, Guava, local Redis client): very low-latency for hot, ephemeral data per instance (session data, computed results). Good for single-node or read-mostly per-instance caching; not suitable for cross-instance sharing.

- CDN / edge cache: caches static assets and cacheable API responses at the edge (images, JS/CSS, public GET responses). Best for global scale, reduces origin load and latency. Use TTLs, cache-control, and Vary headers.

- Distributed cache (centralized cluster: Redis/Memcached): shared fast cache across app servers for session store, frequent reads, leaderboard, feature flags. Provides consistency options (single source), persistence trade-offs.

- Write-through: application writes to cache and backing store synchronously. Simpler consistency (cache always up-to-date) at the cost of higher write latency—good when read-after-write consistency is required.

- Write-back (write-behind): write to cache immediately; asynchronously flush to backing store. Improves write latency and throughput but risks data loss on cache failure—use only when eventual durability is acceptable and with safeguards.

- Read-through: cache handles loading on misses (via loader). Simplifies app logic and avoids thundering herd with locking or single-flight mechanisms.

Invalidation strategies:- TTLs (time-based expiration) — simple but can serve stale data.- Explicit invalidation / purge — API to remove keys on updates; necessary for strong freshness.- Versioned keys / cache-busting — include data version or timestamp in keys to avoid complex invalidation.- Cache-aside (application controls populate/invalidate) — common with distributed caches.- Stale-while-revalidate — serve stale while background refreshes.

Cache coherency concerns:- Stale reads after updates (race conditions between read and write).- Race/thundering herd on miss: use locking/single-flight.- Partial failures: cache may be outdated after write-back; ensure durability/replication.- Consistency vs. performance trade-off: choose eventual vs. strong consistency per use case.- Multi-region replication: cross-region invalidation latency.

As a solutions architect, pick patterns combining CDN for public assets, distributed cache for shared fast reads, and in-memory for per-instance hot paths; use TTL + explicit invalidation and versioning for critical data, and prefer write-through or read-through when strong consistency is needed.

HardTechnical

24 practiced

Design a payments API and backend to ensure exactly-once processing semantics for customer charges in the presence of client retries, network partitions, and multi-step workflows. Discuss idempotency keys, deduplication stores, two-phase commit alternatives, and reconciliation strategies for disputed charges.

Sample Answer

Requirements & constraints:- Exactly-once customer charges despite client retries, network partitions, and multi-step workflows.- External payment gateway calls (at-least-once) and internal ledger must stay consistent, auditable, and reconcilable.- Low latency, high throughput, and strong audit trails for disputes.

High-level design:- API accepts requests with client-supplied idempotency_key (UUID/v4, TTL, bounded length).- Fronting service (API gateway) normalizes requests, authenticates, and forwards to Payments Orchestrator.

Idempotency & deduplication:- Use an immutable DedupStore keyed by (merchant_id, idempotency_key). Value: {request_hash, status: PENDING|COMPLETED|FAILED, ledger_tx_id, gateway_tx_id, created_at, expires_at}.- On request: atomically upsert-if-not-exists (execute via conditional write in DB like Postgres INSERT ... ON CONFLICT DO NOTHING or a single-row DynamoDB conditional put). If existing: - If COMPLETED: return stored result. - If PENDING: return 202 Accepted / "in progress". - If FAILED and retry-allowed: allow new attempt only if request_hash matches (prevents replay with different amounts).

Exactly-once ledger update:- Use single-writer ledger partitioning per customer/payment-method to serialize balance updates (optimistic locking or per-customer stream).- Persist ledger entry and DedupStore update in one atomic operation where possible (same DB transaction). If external gateway call needed first, use outbox pattern.

Outbox + reliable delivery:- When orchestration requires external charge: - Create a local 'ChargeIntent' row and write an outbox event in same DB transaction (ensures local durability). - Background transmitter reads outbox exactly-once (marking rows with compare-and-set) and calls gateway with idempotency_key derived from our dedup key (gateway idempotency when supported). - On gateway response, update DedupStore and ledger in a transaction: mark COMPLETED and insert ledger entry.

Alternatives to 2PC:- Avoid two-phase commit across internal DB and external gateways. Use Saga patterns + outbox to achieve eventual consistency with compensating actions.- For multi-step workflows (authorization → capture → settlement), model each step as a saga participant with state machine persisted; use idempotent step handlers keyed by (idempotency_key, step).

Failure modes & handling:- Client retries: dedup store prevents duplicate processing; request_hash ensures idempotency semantics include payload.- Network partitions: PENDING entries act as locks; background reconciliation scans long-running PENDING and retries or marks FAILED after timeout with operator alert.- Partial succeed (gateway charged but ledger not updated): transmitter must persist gateway_tx_id; reconciliation daemon reads gateway reports/webhooks and reconciles by creating missing ledger entries using idempotency_key/gateway_tx_id lookup.

Reconciliation & disputes:- Maintain immutable audit trail: inbound request, DedupStore events, outbox events, gateway responses, ledger entries, webhooks, and user notifications.- Periodic reconciliation jobs: - Compare gateway settlement reports to ledger: create adjustment entries for gaps, mark duplicates and generate alerts. - Use a reconciliation queue to surface manual review items (mismatched amounts, unknown gateway_tx_id).- Disputed charges: - On dispute, create a DisputeCase linked to ledger_tx_id and gateway_tx_id. - Immediately apply a provisional reversal (reversal ledger entry with "pending dispute" flag) to avoid double-counting. - Keep evidence bundle and async workflow to submit evidence to gateway; on resolution, finalize reversal or reinstate charge. - Maintain SLA-driven escalation and audit logs for legal/compliance.

Operational & security considerations:- TTL for idempotency keys and archival policy.- Rate-limit idempotency_key usage per merchant to avoid DoS.- Strong monitoring: metrics for duplicate attempts, long-PENDING counts, reconciliation drift, failed outbox deliveries.- Encryption of PII, PCI compliance for card data (tokenize at ingestion or use vault), authorization scopes per merchant.- Chaos-tested failure scenarios; replayable audit logs for forensic recovery.

Why this meets exactly-once needs:- Local atomicity (dedup + ledger) where possible prevents double-write.- Outbox + idempotent gateway calls make interactions with external systems safe and retryable.- DedupStore + request_hash prevents client replay with modified payloads.- Reconciliation and dispute flows cover edge cases where eventual consistency windows expose inconsistencies, providing human and automated remediation.

MediumTechnical

16 practiced

Case Study: You're supporting sales for a prospect who requires an architecture that supports 99.99% uptime, multi-region read locality, encryption-at-rest, and on-prem connectors to legacy systems. Sketch a solution you would present during a technical presales call including key trade-offs, major components, and a one-page risk assessment for the customer.

Sample Answer

Requirements clarification:- 99.99% uptime (<=52.56 min/year downtime), multi-region read locality, encryption-at-rest, on-prem connectors to legacy systems (low-latency, secure).High-level architecture:- Multi-region active-active deployment across 2+ cloud regions + optional DR region.- Global load balancing (DNS + anycast or cloud global LB) with latency-based routing for read locality.- Data layer: primary-write region per partition using geo-partitioning; global replication via change-data-capture (CDC) or a managed global database (e.g., CockroachDB / Spanner / Cosmos DB) depending on consistency needs.- Caching: regional read caches (Redis or CDN + edge caches) to serve local reads.- Encryption: KMS-managed CMEK for at-rest encryption; TLS 1.2+/mTLS for in-flight; HSM for higher compliance.- On-prem connectors: secure reverse-proxy / tunnel (e.g., VPN or AWS Direct Connect / Azure ExpressRoute) with connector adapters (lightweight agent) exposing APIs or MQ for legacy systems; use message queues to buffer spikes.- Control plane: central orchestration (Terraform/Ansible), health monitoring, circuit breakers, and automated failover runbooks.Major components:1. Global LB + latency-based DNS2. Regional API gateway + autoscaling service mesh (mTLS)3. Managed global DB or CDC + regional read replicas4. Regional Redis caches5. Secure hybrid network (VPN/DirectConnect) + connector agents & message queue6. KMS/HSM, SIEM, monitoring & SLO dashboardKey trade-offs:- Strong consistency vs read locality: global strong consistency (Spanner) simplifies correctness but increases write latency; eventual/causal consistency plus conflict resolution reduces write latency and improves locality.- Managed DB vs self-managed: managed reduces ops and improves uptime SLA; self-managed gives cost/control.- Active-active complexity: higher availability and read locality, but requires reconciliation and careful partitioning.One-page risk assessment (Likelihood / Impact / Mitigation):- Network outage between regions — Medium / High — Use multi-cloud or separate providers, redundant links, traffic failover, degrade gracefully to read-only.- Split-brain on active-active DB — Low / High — Use leader leases, quorum, automated detection, strong replication guarantees, periodic reconciliation.- Legacy connector failure / slowdowns — High / Medium — Buffering queues, backpressure, circuit breakers, local retries, SLA with on-prem ops.- Encryption key compromise — Low / High — HSM-backed keys, key rotation, least privilege, audit logs.- Operational runbook gaps — Medium / Medium — Automated playbooks, runbook drills, SRE on-call, run failure injection tests.SLA & next steps:- Propose proof-of-concept: regional read locality test, failover drill, connector integration pilot. Estimate costs and map to SLA with SLOs and proposed vendor choices after discovery (consistency, throughput, compliance).

Unlock Full Question Bank

Get access to hundreds of Solution Architecture and Design interview questions and detailed answers.

Join thousands of developers preparing for their dream job.