Requirements to Architecture Mapping Questions

Bridges business and customer requirements to concrete architectural or non functional specifications. Candidates should extract throughput, concurrency, availability, latency, durability, security, compliance and budget constraints from scenarios and translate them into measurable goals such as requests per second targets, latency SLOs, durability levels, retention and encryption requirements. The topic includes creating a requirements matrix that directly informs component choices, capacity planning, and trade off justification.

HardTechnical

61 practiced

Hard: Create an approach to apportion a limited error budget across multiple teams/services that contribute to a composite SLO. How do you allocate the budget, handle shared dependencies, and govern consumption to avoid noisy neighbor behavior? Include enforcement and reporting mechanisms.

Sample Answer

Situation: Our product exposes a composite SLO (e.g., "checkout success rate") assembled from multiple services (frontend, auth, cart, payment, third‑party gateways). We need a repeatable approach to split a limited error budget, manage shared dependencies, and prevent noisy neighbors.

Approach (what I’d design):1. Clarify business priorities and metrics — map each SLI to the composite SLO and annotate traffic fraction, user impact, and recovery cost.2. Hierarchical error‑budget allocation: - Top-level budget = allowed downtime/errors for composite SLO. - Allocate to services proportionally by impact (weighted by traffic and criticality) with a minimum reserve for small teams. - Create a shared‑dependency pool for third‑party or infra components that multiple teams draw from.3. Shared dependencies handling: - Charge consumption from the shared pool when failures are traced to shared components. - For cross‑team features, use tagging in traces/span metadata so budget attribution is automatic. - Maintain a “service owner” for dependencies to coordinate fixes and prioritize mitigations.

Governance & anti‑noisy‑neighbor controls:- Define policy: thresholds (burn rate), escalation rules, and throttles. Example: if burn rate >5x sustained for 10m, auto‑trigger mitigations.- Automated enforcement: - Circuit breakers/feature flags to isolate noisy services. - Admission control: limit non‑critical traffic or reduce retry rates for services exceeding budget. - Rate limits and token buckets per service tied to remaining budget.- Human governance: - SLO committee reviews persistent overruns; require remediation plans and temporary change freezes for repeat offenders. - Quarterly rebalancing of allocations based on usage and business changes.

Instrumentation, enforcement and reporting:- Instrumentation: distributed tracing, request tagging with team/service ids, standardized SLI collection (latency, availability, errors).- Real‑time dashboards: per‑service and composite burn rate, remaining budget %, heatmaps for shared pool usage.- Alerts: - Informational at 20% of budget used. - Actionable at 50% and critical at 80% with runbook links. - Burn‑rate alerts trigger automated mitigation pipelines.- Reporting: weekly digest to stakeholders, monthly RCA for budget exhaustions with owners, SLIs, and remediation status.- Audit trail: immutable logs of budget consumption, automated attribution, and mitigations executed for compliance.

Example enforcement flow:- Payment service burn rate crosses critical threshold -> alert fires, automated feature flag rolls back nonessential features, rate limiter tightens, paging to oncall. Shared‑pool meter shows third‑party gateway used 60% of impact; responsibility split triggers joint incident process.

Outcomes and tradeoffs:- Tradeoff: strict throttling increases user latency/denials but preserves composite SLO and prevents systemic outages.- Benefit: transparent cost of reliability per team, faster isolation of noisy neighbors, predictable business risk.- Continuous improvement: use postmortems and capacity planning to adjust allocations and reduce shared pool reliance over time.

This design balances automated controls, clear ownership, measurable attribution, and governance so teams can move fast while protecting the composite SLO.

EasyTechnical

55 practiced

Given a high-level requirement: 'Support peak traffic of 1M daily active users with global reach', describe the immediate questions you would ask stakeholders to convert this into throughput and concurrency targets (requests per second, concurrent sessions). Show how you'd estimate RPS and concurrency for an initial architecture discussion.

HardSystem Design

52 practiced

Design question: The application needs to support configurable tenant SLAs (bronze/silver/gold) with different throughput and latency guarantees. Propose an architecture that enforces differentiated SLAs at runtime, describes quota enforcement, isolation strategies, and monitoring per tenant.

Sample Answer

Requirements & constraints:- Tenants grouped into bronze/silver/gold with distinct throughput (rps) and p99 latency guarantees.- Enforcement must be runtime-configurable, fair, isolated (no noisy neighbor), observable per-tenant, and scalable to thousands of tenants.

High-level architecture:- Control Plane: SLA Management Service (stores SLA profiles, quotas, policies) + Policy Push component.- Data Plane: Edge/API Gateway → Ingress Rate Limiter & Router → Tenant Execution Pool(s) → Backend services.- Observability: Metrics pipeline (Prometheus/Pushgateway → TSDB), tracing (Jaeger), per-tenant dashboards + alerting.

Core components & responsibilities:1. SLA Management Service: CRUD for tenant SLAs, versioned policy objects, exposes API for ops and automation.2. Policy Distributor: Pushes policies to rate limiters and orchestration layer (via xDS or config store like Consul/etcd).3. Distributed Rate Limiter (data plane): Token-bucket/leaky-bucket per-tenant token stores (local + Redis or a consistent sharded cache for global quotas). Supports hierarchical quotas: global tenant quota + per-endpoint override.4. Priority Scheduler & Execution Pools: Assign requests to prioritized queues (gold > silver > bronze) with weighted fair-queuing to meet latency SLOs. Use separate worker pools or cgroups/Kubernetes QoS classes for stronger isolation.5. Circuit breaker & graceful degradation: For overloaded tenants, apply shed-lower-priority features (degraded responses) rather than hard failures.6. Resource Isolation: Namespace-level CPU/memory limits in Kubernetes, dedicated node pools for top-tier tenants (optional), or colocated with strict cgroup limits. Storage I/O QoS via provisioned IOPS for gold.7. Monitoring & Enforcement Feedback: Emit per-tenant metrics: rps, latency percentiles, token consumption, drops, queue length. Alert on SLA breaches and apply automated remediation (scale, throttle, notify).

Data flow (example):1. Request arrives at API Gateway, extracts tenant-id.2. Gateway consults local rate limiter replica; token available = forward to tenant queue with priority weight.3. Worker processes request; backend latency traced; metrics emitted to central TSDB.4. If limiter denies, return configured fallback (429 or degraded response) and log for billing/alerts.

Quota enforcement details:- Hybrid approach: fast-path local token bucket with periodic refill synced to central Redis or CRDT store for strong consistency on global quotas.- Burst allowance tuned per tier (gold small burst, bronze larger but lower sustained).- Hierarchical quotas: per-tenant overall + per-endpoint to prevent single hot endpoint from exhausting quota.

Isolation strategies:- Soft isolation: logical caps, priority queues, throttling.- Hard isolation: separate node pools, namespace-level resource quotas, dedicated databases or DB partitions for high-tier tenants.- I/O isolation via storage classes with QoS.

Monitoring & SLO process:- Capture p50/p90/p99 latency, error rates, saturation, token consumption per tenant.- Dashboards per tenant + aggregated views.- SLA alerting: automated escalation (scale-up, notify account owner, throttle lower tiers).- SLA reporting for billing and audits.

Scalability & trade-offs:- Local limiters give low latency; central store enables strong global enforcement but adds latency—hybrid balances both.- Hard isolation increases cost (dedicated nodes) but reduces noisy-neighbor risk; offer as premium option.- Prioritization can starve low tiers—use minimum guaranteed capacity and fair-sharing controls.

Why this design:- Separates control vs data plane for operational flexibility.- Hybrid quota enforcement meets latency and global correctness needs.- Combines software throttling and infrastructure limits to provide predictable SLAs while allowing cost/performance tiering.

EasyTechnical

92 practiced

A customer requires encryption-at-rest and encryption-in-transit for all PII. As a Solutions Architect, list at least five measurable or implementable architecture requirements you would add (e.g., key rotation frequency, algorithm choices, KMS constraints). Explain why each is important.

Sample Answer

1) Key algorithm and strength: Require AES-256-GCM for data-at-rest and TLS1.2+ or TLS1.3 with AEAD ciphers (e.g., TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384). Why: Specifies provably strong, industry-accepted primitives and ensures authenticated encryption to prevent tampering.

2) Key management: Use HSM-backed KMS (FIPS 140-2/3 Level 2+ or cloud HSM) with Customer-Managed Keys (CMKs) and enforce KMIP or cloud KMS APIs. Why: Hardware protection and customer control reduce risk of key compromise and meet compliance requirements.

3) Key rotation & lifecycle: Rotate data-encryption keys every 90 days, rotate master keys annually, and retain key versions for 1 year for recovery; provide automated rollover with zero-downtime re-encryption via envelope encryption. Why: Limits exposure window if a key is compromised and ensures recoverability and operational automation.

4) Access controls & separation of duties: Enforce RBAC for KMS operations, require MFA for key-admin roles, separate privileges for key usage vs. key management, and log/alert any Create/Decrypt/Sign operations in real time. Why: Minimizes insider risk and provides traceability for audits and incident response.

5) Encryption-in-transit requirements: Enforce TLS mutual authentication for service-to-service PII flows, require Perfect Forward Secrecy (ECDHE), reject weak ciphers, and mandate certificate rotation every 90 days (or use short-lived certs). Why: Prevents MITM, reduces impact of credential compromise, and ensures secure service communications.

6) Audit, monitoring & retention: Log all KMS and TLS certificate events to immutable audit store (SIEM) with 7+ years retention, enable integrity checks and alerting for anomalous key usage. Why: Provides measurable audit trail for compliance, supports forensic investigations.

7) Backup and storage constraints: Encrypt backups with separate CMKs, enforce dedup/replication paths only to approved regions, and require at-rest encryption for snapshots and object stores. Why: Prevents lateral exposure through backups and controls geographic risk.

Each item above is measurable (algorithm names, rotation intervals, FIPS level, retention periods, TLS versions, RBAC/MFA requirements) and implementable via cloud KMS/HSM, CI/CD cert automation, IAM policies, and SIEM integrations.

MediumTechnical

55 practiced

Scenario: The customer requires 'no single point of failure' for a core API but will only budget for a single active region. Propose architectural mitigations to meet 'no single point of failure' within a single region and explain the remaining risks that must be communicated to the customer.

Sample Answer

Situation: Customer requires “no single point of failure” for a core API but will only fund a single active region. Below I propose pragmatic single-region architecture mitigations and the residual risks you must communicate.

Proposed mitigations (single region, multi-AZ design)- Deploy across ≥3 availability zones (AZs): stateless API instances in an autoscaling group per AZ to tolerate AZ failure.- Global/regional load balancer with health checks and cross-AZ routing to eliminate a single LB failure (use managed LB with multi-AZ control plane).- Database: primary with synchronous or semi-synchronous replicas across AZs (multi-AZ managed RDBMS) plus automatic failover and promotion.- Storage: use replicated object/block storage that’s AZ-redundant (managed S3/Blob equivalents).- Control plane redundancy: run multiple control-plane instances (e.g., API gateways, auth, config) across AZs, and avoid single-host bastions.- Network: redundant NAT/gateway appliances, multiple subnets and route tables, and health-checked private connectivity between components.- Automation & operations: automated failover playbooks, health-driven traffic shifts, runbooks, active monitoring/alerting, synthetic transactions, and regular DR drills within region.- Data protection: continuous backups, point-in-time recovery, and cross-AZ read replicas for read scaling and warm failover.- Chaos testing & runbooks: scheduled AZ-failure drills and runbook validation.

Remaining risks to communicate- Regional or provider-level outage: a region-wide outage (power, network, or provider control-plane outage) will still cause full service loss.- Correlated failures: bugs, misconfigurations, or ransomware can impact all AZs simultaneously (software/configuration single points).- RTO/RPO limits: cross-AZ replication reduces but does not eliminate data loss potential depending on replication mode; define measurable RTO/RPO.- Third-party dependencies: SaaS or upstream APIs hosted only in that region are single points.- Operational risk: human error during failover or deployments can take the service offline.- Cost/trade-offs: synchronous replication and >3 AZs increase cost and latency; balance consistency vs availability.

Recommendation and next steps- Agree on measurable SLA, RTO/RPO, and an acceptance of residual risk or budget for a secondary region (DR failover region on standby or pilot warm replica).- Deliver an architecture diagram, runbooks, and a DR test plan; estimate incremental costs for higher resilience vs residual-risk acceptance.

Unlock Full Question Bank

Get access to hundreds of Requirements to Architecture Mapping interview questions and detailed answers.

Join thousands of developers preparing for their dream job.