Fundamental concepts and design patterns for cloud based systems and services. Topics include core service categories such as compute, storage, networking and databases, virtual machines and containers, serverless computing, managed services, and infrastructure as code. Understand deployment and service models including infrastructure as a service, platform as a service, and software as a service. Evaluate architectural patterns including monolithic, microservices, and serverless approaches, and how they influence scalability, availability, reliability, performance, security, and cost. For more senior roles include distributed systems concepts, consistency and partitioning models, trade off analysis, fault isolation, observability and operational practices in cloud native design.
EasyTechnical
22 practiced
For a stateless web application that experiences unpredictable spikes in traffic and also runs occasional heavy background batch jobs, decide when to use virtual machines (VMs), containers (Kubernetes), or serverless. As a cloud architect, explain trade-offs in scalability, operational overhead, latency (cold starts), cost, and developer velocity.
Sample Answer
**Situation & recommendation (short)** As a cloud architect I'd choose a mixed strategy: serverless for unpredictable short-lived spikes, Kubernetes (containers) for steady web workloads needing control, and VMs for heavy batch jobs or legacy dependencies. Blend reduces risk while optimizing cost and velocity.**Trade-offs by dimension**- Scalability: - Serverless: near-infinite automatic scaling for bursts. - Kubernetes: fast autoscaling (HPA/Cluster Autoscaler) but requires tuning and headroom. - VMs: vertical/horizontal scaling slower; better for predictable capacity.- Operational overhead: - Serverless: lowest ops (no infra management). - Kubernetes: moderate (cluster lifecycle, CI/CD, observability). - VMs: highest (OS patching, images, monitoring).- Latency / cold starts: - Serverless: possible cold starts—mitigate with provisioned concurrency or lightweight functions. - Kubernetes/VMs: consistently warm; lower latency for long-running connections.- Cost: - Serverless: cost-efficient for spiky, low-duty workloads; can be expensive for sustained high throughput. - Kubernetes: cost-efficient at scale with bin-packing; some steady infra cost. - VMs: predictable costs; can be cheaper for heavy, long-running batch when optimized (spot/preemptible).- Developer velocity: - Serverless: fastest for simple endpoints and integration with managed services. - Kubernetes: good for polyglot apps, reproducible infra; requires more DevOps practice. - VMs: slowest iteration, but sometimes necessary.**Concrete pattern**- Host stateless APIs on Kubernetes for most traffic; expose via ingress + autoscaler. - Front bursty endpoints or webhooks with serverless functions or API Gateway + Lambdas; use provisioned concurrency for SLAs. - Run nightly heavy ETL batches on VM/managed batch services (Dataproc, Batch) using spot instances and autoscaling; or run on separate Kubernetes node pool with taints if containerized.**Why this balance**This hybrid approach gives rapid scaling for spikes, stable low-latency handling for core services, control and cost-efficiency for heavy jobs, and incremental operational overhead aligned with business risk and developer needs.
EasyTechnical
22 practiced
List practical high availability strategies you would apply within a single cloud region for a stateless service. Discuss load balancing, autoscaling across availability zones, health checks, instance replacement, and how to validate these HA measures through testing and chaos exercises.
Sample Answer
**Approach overview**Design HA inside one cloud region by distributing stateless service across multiple availability zones (AZs), using intelligent load balancing, autoscaling, proactive health checks and automated instance replacement — then validate with targeted tests and chaos exercises.**Load balancing**- Use regional L4/L7 load balancer (e.g., ALB/NGINX/GCP LB) with cross-AZ routing and session‑stickiness disabled for stateless services.- Configure weighted routing and connection draining to avoid dropping in-flight requests during deployments.**Autoscaling across AZs**- Place instances in an autoscaling group with subnets in >=3 AZs.- Use target tracking + step scaling based on CPU/latency/request-per-second and custom metrics (error rate, queue length).- Use AZ rebalancing to keep capacity even across zones.**Health checks & instance replacement**- Implement both external (load-balancer) and internal (application /ready /live) health probes with short failure thresholds.- If failing, LB removes instance from rotation; autoscaler/instance lifecycle manager terminates and provisions replacement automatically.- Bake images/containers and use immutable deployments to avoid configuration drift.**Validation & chaos testing**- Run non‑production smoke tests, synthetic traffic and load tests (locust/k6) across AZs.- Simulate failures: AZ latency injection, instance termination, LB target removal, network partition. Use tools like Chaos Monkey, LitmusChaos or bespoke scripts.- Validate SLOs/SLIs (availability, p95 latency, error rate) and observe autoscaling behavior, traffic redistribution, and recovery time (MTTR).- Automate runbooks and run periodic game days to confirm people + automation respond correctly.
HardSystem Design
26 practiced
Design a globally distributed, low-latency data architecture to serve 50 million monthly users where each user's reads need strong consistency within their primary region but can be eventually consistent across regions. Describe data partitioning, replication topology, routing, conflict resolution, and how to meet latency SLAs while preserving correctness.
Sample Answer
**Clarify requirements & constraints**- 50M monthly active users (assume ~5–10M concurrent regional active users), strong consistency for reads in a user’s primary region, eventual cross-region; target read latency SLA ≤50ms P95 globally; tolerate cross-region replication lag.**High-level design**- Each user assigned a single primary region (geo-anchoring) based on signup or latency; all strong-consistent reads/writes for that user serve from that region.**Data partitioning**- Partition by user-id using consistent hashing/sharding key: user-id -> shard -> region. Shards sized to fit region capacity; re-sharding via hash ring and virtual nodes to balance.**Replication topology**- Within-region: single-writer, multiple read replicas using leader-follower (leader in primary region). Leader applies writes synchronously to local replicas via raft/Paxos to guarantee local strong consistency.- Cross-region: asynchronous geo-replication from each primary region’s leader to secondary regions (fan-out). Use change-log (CDC) with ordered, idempotent events.**Routing**- Global front door (edge LB + DNS + Anycast) with geolocation routing to user's primary region. If primary region unavailable, failover to next preferred region with last-known-writes replayed.**Conflict resolution**- Per-user single-writer model avoids most conflicts. For multi-writer cases (e.g., admin tools), use per-record last-writer-win with hybrid logical clocks (HLC) and application-level merge hooks for domain-specific reconciliation. Events carry HLC timestamps and monotonic sequence numbers.**Meeting latency SLAs**- Ensure leaders colocated in primary region; use local sync replication (raft) to keep read-after-write within region; serve reads from leader or local read-replica with read lease to provide linearizability within region.- Optimize network: regional caching at edge for non-sensitive reads, TCP tuning, connection pooling, and colocated services.- Observability: SLOs, SLIs (P95 read latency, replication lag), circuit-breakers, backpressure, and automated failover playbooks.**Trade-offs**- Single-writer per user simplifies correctness but complicates dynamic region reassignment; asynchronous cross-region replication favors availability/latency at cost of eventual consistency globally.
HardTechnical
23 practiced
Design resilience patterns for a payments service that must continue to operate correctly during partial regional network partitions. Explain how to apply idempotency keys, idempotent APIs, at-least-once vs exactly-once semantics, distributed sagas and compensating transactions, circuit breakers, queueing, deduplication, and auditing to prevent double-charges and preserve correctness.
Sample Answer
**Clarify constraints & goals**- Preserve correctness (no double-charges), high availability during regional partitions, eventual consistency across regions, clear auditability, bounded user latency.**High-level approach**- Combine idempotent APIs + global idempotency keys, asynchronous durable queues, distributed saga orchestration with compensating transactions, deduplication stores, circuit breakers, and immutable audit logs.**Key components & how to apply**- Idempotency keys: clients generate a UUID per logical payment attempt and send with request. All write paths check a strongly consistent idempotency store (multi-region consensus or single-region leader) before processing; if seen, return stored outcome.- Idempotent APIs: design POST /payments to be safe to retry; include idempotency-key header and return canonical result.- At-least-once vs exactly-once: aim for idempotent at-least-once delivery. Exactly-once across distributed partitions is expensive; use idempotency to achieve effective exactly-once semantics for charges.- Queueing & deduplication: use durable queues (regional with replication) for downstream processors; attach idempotency-key to messages and have worker-level deduplication cache (LRU + persistent store) before calling gateways.- Distributed sagas & compensations: model payment as saga steps (reserve funds, capture, notify). On failures or partitions, run compensating actions (void reservation, refund) triggered by saga coordinator or message-driven timeout. Persist saga state in durable, replicated store.- Circuit breakers & backpressure: per-gateway circuit breakers to avoid cascading failures during partition; fail fast to queue and mark saga for compensation retries.- Auditing & observability: immutable append-only audit log (WORM S3/BigQuery) and end-to-end traces containing idempotency-key and saga-id for forensic replay.- Conflict & partition handling: during partition prefer availability for reads, but direct mutation that could double-charge must require idempotency-confirmation from an authoritative idempotency store (leader or consensus); when leader unreachable, reject new charges or queue them as provisional with explicit user-facing pending state.- Reconciliation: periodic reconciliation job that scans audit logs, idempotency table, gateway transactions to detect anomalies and trigger compensations or manual review.**Trade-offs**- Strong idempotency store increases latency/complexity but prevents double-charges. Queuing + retries reduce user latency at cost of eventual correctness and additional UX (pending state). Exactly-once is avoided; practical correctness obtained via idempotency + compensations.**Why this works**- Idempotency provides logical uniqueness; queues and retries provide resilience to partitions; sagas + compensations ensure eventual correctness; circuit breakers and auditing protect stability and traceability—together preventing double-charges while enabling continued operation during partial partitions.
HardTechnical
20 practiced
Create a detailed plan to migrate 10 petabytes of on-premises data to a public cloud with minimal downtime and controlled cost. Cover options such as initial bulk transfer (physical appliances), online transfer with dedicated links, staging and verification, continuous sync using CDC, cutover mechanics, security during transit, and rollback considerations.
Sample Answer
**Approach overview**Migrate 10 PB with hybrid: initial bulk (physical appliances) to seed cloud, then online sync with dedicated link + CDC for near-zero downtime. Emphasize staging, verification, secure transfer, cost control, and clear rollback.**Plan**- Discovery & sizing - Inventory datasets, throughput, change rate, retention, RPO/RTO. - Estimate network egress/ingress costs and appliance rental vs long-haul transfer cost.- Initial bulk transfer (physical) - Use vendor appliance: AWS Snowball/Snowmobile, Azure Data Box Heavy, or GCP Transfer Appliance. - Ship encrypted appliances; parallelize shipments by dataset priority (hot vs cold). - On arrival, import into cloud staging buckets with server-side encryption and KMS-managed keys.- Online transfer with dedicated links - Provision Direct Connect / ExpressRoute / Cloud Interconnect with redundant circuits sized from change-rate forecast. - Use WAN optimization (TCP tuning, compression) and negotiated L2/L3 QoS. Estimate monthly circuits vs appliance marginal cost.- Staging & verification - Stage data into immutable staging buckets and verify with checksums (MD5/SHA256) and file-level manifests. - Perform sample integrity and application-level acceptance tests.- Continuous sync using CDC - Deploy CDC pipeline (Debezium / GoldenGate / AWS DMS) capturing DB changes; stream to cloud via secure VPN or dedicated link into Kinesis/ EventHub / PubSub, then apply to cloud DB. - For file/object deltas, use rsync/azcopy/gcloud storage transfer with object versioning.- Cutover mechanics - Freeze or throttle writes for brief window if needed; use dual-write during ramp-down if app supports. - Update DNS/load-balancer to cloud endpoints, validate transactions against canary datasets, monitor lag metrics. - Post-cutover reconcile with final checksum and application smoke tests.- Security during transit - Encrypt at source (client-side) + TLS in-flight + server-side encryption in cloud; use KMS/HSM and strict IAM policies. - Use signed manifests, immutable logs, and monitor with IDS/IPS and SIEM.- Rollback considerations - Maintain rollback runbook: keep sources writable, retain the source canonical until verification period ends, snapshot cloud state prior to cutover. - Plan for reverse replication via same dedicated link; validate performance and timelines.**Cost & timeline controls**- Use staged approach: migrate cold data via appliances (cheaper), hot via network.- Model costs: appliance rental + transfer + egress + dedicated link monthly + storage tiering; archive infrequently accessed data to cheaper classes immediately.- Run pilot migration (1–5 TB) to validate timings, checksums, and CDC lag, then scale.**Monitoring & automation**- Automate manifests, checksum validation, retry logic, and alerting.- Track metrics: bytes transferred, CDC lag, error rates, time-to-consistency.This plan provides a repeatable, secure, and cost-aware migration with minimal downtime and clear rollback paths.
Unlock Full Question Bank
Get access to hundreds of Cloud Architecture Fundamentals interview questions and detailed answers.
