Architecture Design Principles Questions
Fundamental architectural principles that guide design choices across systems: separation of concerns, loose coupling, modularity, encapsulation, resilience, observability, security by design, scalability by design, and maintainability. This topic evaluates a candidate's ability to apply these core principles, recognize anti patterns, and choose appropriate patterns based on constraints and non functional requirements.
MediumTechnical
116 practiced
Define an API versioning and deprecation policy for a public REST API consumed by external clients. Cover versioning scheme (URI vs header), handling breaking changes, deprecation timelines, backward-compatible schema evolution (additive changes), and a communication/staging plan for clients.
Sample Answer
Policy summary: Use explicit versioning for breaking changes and lightweight header/version negotiation for non-breaking evolution. Provide clear timelines, tooling, and communication so external clients can migrate predictably.Versioning scheme- Major-in-URI for breaking changes: /v1/... /v2/... — easy to cache, monitor, and route; explicit and discoverable.- Minor/feature/versioning via headers or media types for opt-in capabilities: Accept: application/vnd.myapi.v1+json; X-API-Preview: feature-name. This allows progressive rollout without introducing new URI endpoints.Handling breaking changes- Any change that alters request/response semantics (removed fields, renamed types, changed status codes/URL shape) requires a major version bump (new URI).- Maintain old major version until deprecation window expires. Do not change behavior of published major versions.- For urgent security fixes, patch within same major if possible; if impossible, create vN+1 and fast-track communication.Deprecation timelines (example)- Announcement: immediately via changelog, dashboard, email, and API responses (Deprecation and Sunset headers).- Migration window: default 12 months for major versions. Schedule: Announcement -> 90-day reminder -> 30-day reminder -> Sunset date.- Critical/enterprise customers: offer extended support contracts if needed.- Shorter windows (30–90 days) only for critical security issues with clear mitigation.Backward-compatible schema evolution (additive changes)- Allowed without version bump: adding optional fields, new resources/endpoints, additive query params, additional response fields (clients must ignore unknown fields).- Enforce strict rules: make new fields optional or with sensible defaults; avoid changing enum values — add new enum values, not remove.- Use feature flags and preview headers for fields that may become standard later.- Provide clear nullability contracts and avoid changing semantics of existing fields.Communication & staging plan for clients- Publish a public changelog, semantic release notes, migration guides, example diffs, and SDK updates.- Emit Deprecation and Sunset headers in responses for deprecated endpoints: - Deprecation: Thu, 01 Jun 2025 00:00:00 GMT - Sunset: Thu, 01 Jun 2026 00:00:00 GMT - Link: <https://api.mycompany.com/migrations/v1-to-v2>- Provide sandbox/staging endpoints mirroring production for early testing.- Beta program: allow clients to opt-in to new version via header or /beta prefix; collect feedback.- Contract testing and CI: publish OpenAPI/JSON Schema for each version; provide sample Postman collections; run consumer-driven contract tests (PACT) and encourage clients to run them in CI.- Telemetry & metrics: track client usage by version, error rates, and migration progress. Send automated reminders to clients not upgrading.- Support: migration working sessions for top clients, dedicated slack channel, and issue tracker.Enforcement & rollback- During the migration window, route clients to a deprecation page with guidance if they hit sunset endpoints.- No silent breaking changes. Rollbacks happen by reverting the new major or toggling feature flags; preserve the old major until sunset.Success metrics- % of clients migrated before sunset (target 90%)- Reduction in errors linked to deprecated endpoints- Time-to-migrate for active clientsThis policy balances predictability (URI major versions), flexibility (header/preview for additive features), and operational safety (clear timelines, telemetry, and contract testing) to minimize disruption for external consumers.
EasyTechnical
69 practiced
Define 'resilience' in distributed systems and list five resilience patterns (for example: timeouts, retries, circuit breakers, bulkheads, backpressure). For each pattern describe when it should be used and one common pitfall to avoid.
Sample Answer
Resilience in distributed systems is the system’s ability to continue operating correctly despite failures (partial outages, network faults, slow services). It means detecting faults, containing blast radius, degrading gracefully, and recovering automatically.1) Timeouts- When: Always set for remote calls or I/O to avoid waiting indefinitely and holding resources.- Pitfall: Too-short timeouts causing false failures; choose based on p95/p99 latency and include jitter.2) Retries (with backoff)- When: For transient errors (network blips, temporary service overload).- Pitfall: Blind retries can amplify load and thundering herd; use exponential backoff and max attempts.3) Circuit Breaker- When: When a downstream is failing or very slow—open the circuit to fail fast and allow recovery.- Pitfall: Incorrect thresholds or long open windows that prevent recovery; tune for realistic failure modes.4) Bulkheads- When: Isolate resources (threads, connections, containers) per tenant or function to contain failures.- Pitfall: Over-partitioning wastes capacity; under-partitioning fails to contain cascades—balance partitions to workload.5) Backpressure / Rate Limiting- When: When producers risk overwhelming consumers or shared resources (DB, message queues).- Pitfall: Dropping requests without graceful degradation or clear client signaling; provide meaningful responses or queuing.Together these patterns detect, isolate, and control failures—applied with monitoring and careful operational tuning they greatly improve system uptime.
HardSystem Design
65 practiced
Design a saga-based ordering system where placing an order involves inventory, payment, and shipping services. Show both choreography and orchestration approaches, list compensation actions for partial failures, and describe how you would make the overall process observable and eventually consistent.
Sample Answer
Requirements & constraints:- Functional: place order -> reserve inventory, charge payment, schedule shipment; if any step fails, compensate prior steps.- Non-functional: high availability, eventual consistency, idempotency, observability, retries with backoff, support concurrent orders.Choreography approach:- Flow: Order Service publishes OrderCreated event -> Inventory Service subscribes, attempts ReserveInventory, emits InventoryReserved or InventoryReservationFailed; Payment Service listens to InventoryReserved, attempts Charge, emits PaymentSucceeded or PaymentFailed; Shipping Service listens to PaymentSucceeded, creates shipment and emits ShippingScheduled. Order Service subscribes to all events to update order state.- Compensation: on InventoryReservationFailed -> OrderCancelled event. On PaymentFailed -> InventoryService listens and runs ReleaseInventory. On ShippingFailed -> PaymentService listens and issues Refund; InventoryService listens to ShippingFailed and ReleaseInventory if needed.- Pros: loosely coupled, easy to add services. Cons: complex event choreography, harder to reason about failure paths.Orchestration approach:- Flow: An Order Orchestrator (Saga Manager) drives steps sequentially: call Inventory.Reserve(); if success call Payment.Charge(); if success call Shipping.Schedule(); at each step orchestrator records saga state in durable store and emits events for state changes.- Compensation: If Payment.Charge fails -> Orchestrator calls Inventory.Release(); if Shipping.Schedule fails -> Orchestrator calls Payment.Refund() then Inventory.Release(). All compensation calls are idempotent and logged.- Pros: central control, easier to reason and test. Cons: orchestrator as potential bottleneck/single point of failure (mitigate with HA).Compensation design principles:- Each service exposes compensating API (ReleaseInventory, RefundPayment, CancelShipment).- Compensations must be idempotent, take saga-id, and tolerate partial/in-flight states.- Use versioned commands and optimistic concurrency for resources.Observability & eventual consistency:- Saga state store: durable saga table (saga_id, step, status, retries, metadata). Orchestrator updates atomically.- Correlation IDs: propagate saga_id across messages and external APIs.- Tracing: distributed tracing (OpenTelemetry) across services to follow saga.- Metrics & alerts: counters for saga failures, compensation invocations, step latencies, dead-letter queue size.- Auditing: append-only saga event log for troubleshooting and replay.- Dead-letter & manual reconciliation: failed compensations go to DLQ; reconciliation worker attempts retries and notifies ops for manual intervention.- Eventual consistency: clients see order states that may be transient (PENDING → COMPLETED). Provide query model optimized for read (materialized view built from saga events) and expose clear statuses (PENDING_RESERVATION, AWAITING_PAYMENT, COMPENSATING, COMPLETED, FAILED).- Retries: exponential backoff, bounded retries, circuit breakers on downstream services.Trade-offs & robustness:- Choose choreography if many small services and you want lower orchestration coupling. Choose orchestration for stronger central control, transactional clarity, and simpler failure reasoning.- Hybrid: orchestrator for primary happy-path coordination and events for side-effects/notifications.- Ensure contracts, idempotency, timeouts, and monitoring to keep system reliable and debuggable.
HardTechnical
63 practiced
Architect a system to enable rapid product evolution with minimal rewrites. Cover API stability, backward-compatible contracts, adapter layers, contract and integration tests, release practices, and governance to prevent tech debt accumulation. Include how you would balance speed and long-term maintainability.
Sample Answer
Requirements & goals: enable rapid feature delivery while minimizing rewrites, preserve API stability for consumers, detect regressions early, and prevent tech-debt accumulation through governance.High-level approach:- Design for evolution: small cohesive services with explicit public contracts (OpenAPI/GraphQL schemas) and internal modular components. Treat contracts as first-class artefacts.- API stability & backward compatibility: - Use semantic versioning for major breaking versions; prefer additive, non-breaking changes (new fields, endpoints). - Support tolerant parsing: ignore unknown fields; provide defaults. - Maintain compatibility matrix and automated checks comparing schema diffs.- Adapter layer: - Introduce an adapter/anti-corruption layer between external contracts and internal models. Adapters map evolving internal representations to stable external contracts so internals can refactor independently. - Use façade services for major subsystems to centralize translation logic.- Testing strategy: - Contract tests (consumer-driven contracts like Pact) to lock producer/consumer expectations. - Integration tests in CI that run contract stubs and end-to-end flows. - Schema regression tests that fail builds on incompatible contract changes unless explicitly approved. - Canary & shadow traffic in staging to validate behavior under real load.- Release practices: - CI/CD pipelines with feature flags and gradual rollouts (canary, percentage-based). - Backwards-compatible rollout: release server-side changes behind flags, then roll out client migrations. - Clear deprecation policy: publish deprecation timelines, automated telemetry on clients still using old APIs.- Governance to prevent tech debt: - API review board that approves contract-breaking changes, requiring migration plans and migration tooling. - Architectural decision records (ADRs) for major choices; periodic tech-debt sprints and measurable SLAs for debt ageing. - Mandatory definition-of-done includes contract tests, docs, telemetry, and migration guides. - Metrics: track API error rates, client migration progress, number of breaking changes, and code churn.Balancing speed vs maintainability:- Default to local, reversible changes (feature flags, adapters) enabling fast experiments.- Require higher discipline for breaking changes: only when business ROI justifies cost of migration and with tooling to automate client updates.- Invest upfront in automation (contract tests, CI gates, adapters) to keep per-change overhead low but ensure long-term stability.This architecture lets teams move quickly with low friction while enforcing guardrails that prevent accumulation of brittle, unmaintainable APIs.
EasyTechnical
73 practiced
List and define the three pillars of observability. For each pillar, give two concrete signals you would emit from a backend service (for example: trace spans, HTTP request counts) and explain how each helps diagnose a customer-facing latency issue.
Sample Answer
The three pillars of observability are metrics, logs, and traces.1) Metrics — aggregated numeric signals sampled over time.- Signal A: HTTP request count and error rate (per endpoint, per status). How it helps: shows where traffic and failures concentrate; a spike in latency accompanied by increased 5xx rate or a drop in success rate points to backend errors rather than client issues.- Signal B: P95/P99 request latency histogram (per endpoint). How it helps: quantifies tail latency and whether the problem affects a small fraction of requests (P99) or most (P50/P95), guiding whether to hunt rare slow codepaths or systemic bottlenecks.2) Logs — structured, event-level textual records.- Signal A: Request lifecycle logs with timestamps and context IDs (userID, requestID). How it helps: lets you correlate specific slow requests to code paths, input parameters, upstream/downstream calls and surface anomalies (e.g., time spent waiting for DB).- Signal B: Error and warning messages with stack traces and timing. How it helps: reveals root-cause exceptions or retries (e.g., DB timeout, circuit-breaker trips) that explain increased latency.3) Traces — distributed spans showing causal call graphs and timing.- Signal A: End-to-end trace spans with span durations for internal services (e.g., auth, cache, DB). How it helps: pinpoints which downstream call contributes most to end-to-end latency by showing per-span durations and concurrency.- Signal B: Service dependency heatmap / trace sampling showing percent of traces with retries or long queue times. How it helps: reveals systemic issues like queuing, retry storms, or overloaded dependencies versus isolated slow handlers.Together: metrics detect and quantify the problem, logs provide context and details for individual failures, and traces show causal timing across services to identify precise bottlenecks.
Unlock Full Question Bank
Get access to hundreds of Architecture Design Principles interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.