Cloud Architecture and Design Patterns Questions

Designing and evaluating cloud native architectures and common architecture patterns, with attention to service capabilities, limits, and operational and security implications. Topics include compute scaling models for virtual instances, managed compute, serverless functions and container orchestration; storage choice, object storage classes, lifecycle policies and caching strategies; managed relational database architectures with high availability patterns such as multiple availability zone deployments and read replicas; trade offs of serverless approaches including cold start and invocation limits; different load balancing approaches for application level and network level traffic; networking and identity boundary design including virtual networks, subnetting, routing, security groups and access control patterns; backup, recovery and disaster recovery planning; deployment patterns such as blue green and canary releases; scalability strategies, performance and latency considerations; vendor lock in, portability and total cost of ownership trade offs; and operational practices for monitoring, limits management and incident response. Candidates should be able to translate requirements into architecture decisions, justify trade offs, and design for resilience, scalability, performance, security and cost.

HardSystem Design

43 practiced

Design a hybrid cloud architecture connecting an on-premises datacenter to a public cloud for latency-sensitive workloads and strict compliance requirements. Address connectivity (Direct Connect / ExpressRoute / VPN), data locality, caching strategies at the edge, identity federation, network routing, and how to partition workloads to satisfy both latency and compliance constraints.

Sample Answer

**Clarify requirements & constraints**- Latency SLOs (e.g., p99 < 10ms), compliance zones (data residency, encryption, audit), expected throughput, failover RTO/RPO, and which cloud provider (assume AWS/Azure/GCP parity).

**High-level architecture**- Dedicated private link: use Direct Connect / ExpressRoute for primary low-latency path; use IPsec VPN over internet as backup.- Edge PoPs (on-prem or colocated): deploy cache + WAF + CDN PoP for read-heavy assets; use local processing for latency-sensitive functions.

Diagram (logical):on-prem DC <== Direct Connect/ExpressRoute ==> VPC/VNet (cloud) on-prem DC <== IPsec VPN (backup) ==> VPC/VNet Edge PoP <-> Cloud CDN / Regional VPC

**Connectivity**- Provision redundant Direct Connect/ExpressRoute circuits in separate carriers and AZs; BGP with MD5 for session security.- Advertise only necessary prefixes; use prefix-lists and route filters.

**Data locality & partitioning**- Partition by compliance and latency: - Compliance-critical data: keep in on-prem or cloud region in required jurisdiction. Use storage service with customer-managed encryption keys (CMKs) and hold KMS root on-prem if policy demands. - Latency-sensitive compute: colocate near users — run hot path services in on-prem or cloud region connected by Direct Connect. Use async replication for non-sensitive data to other regions. - Bulk/analytics: move to cloud region without strict residency; use ETL jobs to copy sanitized subsets.

**Caching at the edge**- Deploy edge caches/read-through caches (e.g., CloudFront/Front Door + regional Redis/Memcached) and local cache appliances on-prem.- Use cache-coherency patterns: TTLs, cache invalidation via pub/sub over the private link, and conditional GETs.- For write-heavy low-latency needs, use leader-follower with leader local to users; replicate asynchronously to central store.

**Identity federation**- Federate on-prem AD/LDAP to cloud IAM using SAML/OIDC (e.g., ADFS, Azure AD Connect, AWS IAM Identity Center).- Enforce MFA, conditional access, and Just-In-Time role elevation for privileged operations.- Use attribute-based access control (ABAC) and policy-as-code (e.g., Terraform + Sentinel/IaC scanners).

**Network routing & security**- Use BGP communities to steer traffic: prefer Direct Connect for latency-sensitive prefixes; failover to VPN via route metrics.- Implement microsegmentation with security groups / NSGs and host-based firewalls.- Encrypt in transit (TLS 1.3) plus IPsec on connectors; enforce HSTS and client certs where needed.- Monitoring: VPC flow logs, peering flow logs, SIEM integration, synthetic latency checks.

**Operational considerations**- Automate provisioning (IaC), CI/CD, and runbook for failovers.- Test failover monthly; measure p99 latency and compliance audit traces.- Trade-offs: Direct Connect adds cost and provisioning time but reduces latency and increases control; async replication trades immediate consistency for performance.

Result: a hybrid design that keeps regulated data in required boundaries, serves sub-10ms latency paths via dedicated links and edge caches, and federates identity and routing for secure, resilient operation.

EasyTechnical

44 practiced

You must choose storage for three workloads: (1) static website assets and media, (2) a relational database backend, and (3) shared configuration files consumed by containers. For each workload pick object, block, or file storage and justify your choice in terms of durability, latency, throughput, consistency and cost.

HardSystem Design

82 practiced

Design a highly available, low-latency global service that must serve 100k requests per second worldwide with 95th percentile latency under 100ms. The system must operate across three regions and provide strong consistency for some write operations while allowing eventual consistency for others. Describe global traffic distribution, data partitioning, leader election or consensus strategy, database selection and replication approach, and how to meet latency and consistency SLAs.

Sample Answer

**Clarify constraints & goals**- 100k RPS global, 3 regions, p95 <100ms, mixed strong/eventual consistency, cloud-first (AWS/GCP/Azure).

**Global traffic distribution**- Use anycast + global LB (CloudFront+Global Accelerator on AWS / Cloud CDN + Global Load Balancer). - Edge tiers handle TLS termination, caching, and route /cacheable reads to nearest region. - Health-aware geo-routing (weighted by region capacity) with failover.

**Data partitioning**- Shard by user-id / tenant using consistent hashing to evenly distribute load and keep hot keys localized. - Range-sharding for time-series workloads; include key prefixes for region affinity when low-latency reads required.

**Leader election / consensus**- Per-shard leader elected using Raft (managed by a consensus service: etcd/Consul or cloud-managed Spanner/Cloud Spanner uses Paxos internally). - Leaders placed in region minimizing average latency for that shard; automatic reelection on failure; leader stickiness to reduce cross-region write hops.

**Database selection & replication**- For strongly consistent writes: use a globally-replicated SQL store with synchronous or semi-sync replication per-shard (Cloud Spanner / CockroachDB / Cosmos DB with multi-master and strong consistency mode). - For eventual consistency: use regional primary DBs with async replication (Aurora Global DB / Cloud SQL replicas / DynamoDB global tables with eventual). - Read replicas in each region; use change-data-capture for cross-region eventual sync.

**Meeting latency & consistency SLAs**- Route reads to local replicas; cache hot objects at edge (CDN + Redis Global/Regional clusters). - For strong writes: minimize write latency by assigning leader in client’s nearest region for that shard; use fast Raft quorums (3 nodes across 3 regions) but prefer region-local leader and two remote followers—tune quorum size vs RPO. - For operations requiring linearizability, use leader proxying and ensure leader write path completes within SLAs; degrade noncritical features to eventual mode under load. - Autoscale compute and DB read replicas; instrument SLOs with tracing, synthetic tests, and circuit breakers.

**Trade-offs**- Strong consistency increases write latency and complexity; mitigate by limiting strong ops to critical paths and optimizing leader placement.- Use monitoring + runbooks for failover, and periodic chaos testing to validate cross-region behavior.

HardSystem Design

48 practiced

Design a multi-cloud Kubernetes deployment strategy for a SaaS product that must run on both AWS and GCP for redundancy and customer choice. Address CI/CD, secrets management, cluster networking, stateful data replication, and how you'd ensure consistent policy and observability across clouds while minimizing divergence in operational workflows.

Sample Answer

**Clarify goals & constraints**- Run same SaaS on AWS + GCP for redundancy and customer choice- Minimize operational divergence, keep CI/CD, security, observability and networking consistent- Accept cloud-native managed services where multi-cloud alternatives exist

**High-level architecture**- Two independent Kubernetes clusters per region: one in EKS, one in GKE. Use identical cluster provision via Crossplane/Terraform modules to enforce parity.- Control plane: GitOps (Argo CD) repositories drive cluster state; single source-of-truth repos for platform, apps, and infra.

**CI/CD**- Pipeline: Git -> build (GitHub Actions/GitLab CI) -> container registry (ECR/GCR or a single multi-region Artifact Registry) -> push manifests/Helm -> Argo CD sync.- Promote artifacts by immutable tags; Argo CD apps parametrized per cloud (values.yaml) to avoid divergent manifests.

**Secrets management**- Centralized secrets engine: HashiCorp Vault running in HA with replicas in both clouds or use Vault with auto-unseal using cloud KMS (AWS KMS + GCP KMS) via Transit. Store secrets in Vault; inject into pods via Vault CSI driver.- For cloud-managed secrets, mirror only metadata in Vault; avoid storing cloud-specific secrets in code.

**Cluster networking & service mesh**- Use same CNI where possible (Calico) for consistent network policy semantics.- Deploy a cloud-agnostic service mesh (Istio or Linkerd) for mTLS, traffic shaping, and global policies. Use Gateway + Ingress per cloud and a global DNS (Route53 + Cloud DNS with health checks) to steer traffic.

**Stateful data replication**- Prefer managed cross-cloud databases where possible (CockroachDB, YugabyteDB) for geo-replicated SQL with single logical cluster across clouds.- If managed DBs per cloud (RDS/Cloud SQL), implement active-passive multi-region replication and global failover orchestrated by a control plane (e.g., Patroni + external failover controller) and async replication with strong automation for cutover.- Backups: Velero scheduled to object storage in both clouds (S3 and GCS) and cross-copy to ensure recoverability.

**Policy consistency**- Policy-as-code: OPA/Gatekeeper policies enforced in all clusters. Use centralized policy repo; CI gates validate manifests against policy.- Cluster bootstrapping through same modules ensures identical RBAC, node pools, autoscaling settings.

**Observability**- Unified telemetry: Collect logs/metrics/traces with OpenTelemetry to a centralized backend (prefer SaaS APM or a multi-tenant observability layer reachable from both clouds). Alternatively run Prometheus + Cortex/Thanos for long-term metrics with object storage backend per cloud and global query layer.- Traces in Jaeger/Tempo with sampling consistent across clusters; alerts in PagerDuty/Slack unified via Alertmanager federated config.

**Operational minimization of divergence**- Infrastructure as code modules, GitOps, shared Helm charts, shared vault/policy repos.- Run CI/CD, observability, policy tests in centralized pipelines to prevent cluster-specific ad-hoc changes.- Regular DR runbooks and automated failover drills.

**Trade-offs & risks**- Cross-cloud data consistency and latency: choose database topology based on consistency vs availability trade-offs.- Vault HA across clouds increases complexity; alternative is per-cloud Vault clusters with replication.- Egress and inter-cloud costs for data replication.

**Metrics of success**- RPO/RTO targets met in runbooks; successful automated failover tests; <= 10% config drift measured by nightly scans; consistent SLOs/alerts across clouds.

This design balances parity via automation and GitOps, centralizes policies/observability, and uses multi-cloud-ready stateful solutions to minimize operational divergence.

EasyTechnical

53 practiced

Compare blue-green, canary, rolling and A/B deployment strategies. For a stateless API that shares a relational database backend that cannot accept schema-version divergence, which deployment approach would you choose and outline the safe steps to perform the deployment.

Sample Answer

**Compare strategies (brief)**

- Blue‑green: two identical environments (blue = current, green = new). Instant switch-over; simple rollback. Requires duplicate infra and careful DB compatibility.- Canary: route small % of traffic to new version, monitor, then ramp. Low blast radius; good observability.- Rolling update: incrementally replace instances across the fleet. No duplicate environment but requires careful health checks and capacity planning.- A/B testing: routes distinct user segments to different implementations for experiment/metrics; focused on product experiments rather than safe ops rollouts.

**Which to choose (for stateless API + single relational DB that cannot accept schema-version divergence)**

I would use a canary or controlled rolling deployment combined with a safe DB migration pattern (expand-contract). Canary preferred because it limits blast radius and allows metrics-driven ramping while using the same DB.

**Safe deployment steps (operational)**

1. Prepare DB for zero-downtime: - Add additive, backward-compatible columns/tables/indexes (expand step). - Avoid destructive changes until old code removed.

2. Implement feature flags in code so new DB-dependent behavior can be toggled.

3. CI/CD: build and smoke-test image/container; run integration tests against a staging copy of RDS.

4. Canary rollout: - Deploy new version to a small subset (e.g., 5%) via ALB target groups or service weights (ECS/KS/ISTIO). - Monitor errors, latency, DB metrics, and anomaly alerts for a set window.

5. Gradually increase traffic (5% → 25% → 50% → 100%) with health gates and automated rollback thresholds.

6. Once stable, flip feature flag to enable new behavior fully, then perform contract cleanup: - Remove old code paths. - Perform destructive DB migration (drop deprecated columns) during a maintenance window if needed.

7. Post-deploy: - Run data integrity checks, remove migration toggles, scale down rollback artifacts.

**Why this approach**- Preserves DB compatibility, minimizes user impact, provides fast rollback, and leverages cloud load‑balancing and autoscaling features for safe, observable rollouts.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.