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.

MediumSystem Design

44 practiced

Design a Kubernetes cluster strategy for a client operating 50 microservices where most services are stateless but three are stateful (Kafka, Postgres, Redis). Discuss node sizing, namespaces, resource quotas, pod autoscaling, StatefulSets for stateful services, storage provisioning (dynamic vs static), and an upgrade strategy that minimizes downtime.

Sample Answer

Requirements & constraints (clarifying): production-grade cluster for ~50 microservices (mostly stateless), three critical stateful systems: Kafka, Postgres, Redis. High availability, minimal downtime for upgrades, cost-effective scale.

High-level architecture:- Multiple node pools: control plane (managed by provider), system (kube-system), compute (stateless workload), stateful (IO-optimized).- Use managed k8s (EKS/GKE/AKS) if possible for control-plane upgrades and security.

Node sizing & pools:- Compute pool: burstable/standard instances (e.g., m5/azureD2) for web/API services. Autoscale via Cluster Autoscaler.- Stateful pool: 3–5 r5/io-optimized instances (high IOPS, e.g., r5/ i3d) to host Postgres, Kafka, Redis — tainted + dedicated nodeSelector/affinity.- Small spot/low-priority pool for noncritical batch jobs.- Use pod anti-affinity to spread replicas.

Namespaces & resource governance:- One namespace per team or logical domain; infra namespace for stateful operators.- Enforce ResourceQuota + LimitRange per namespace (CPU/memory and object counts).- NetworkPolicies per namespace for isolation.

Pod autoscaling:- HPA for stateless deployments (metrics-server / Prometheus adapter for custom metrics).- Use VPA in “recommend” mode for sizing; combine with HPA (horizontal + vertical).- Cluster Autoscaler to add/remove nodes based on pending pods.

StatefulSets & stateful services:- Deploy Postgres and Redis with StatefulSets, stable network IDs (headless Service), and anti-affinity across nodes/azs.- Kafka via a proven operator (Strimzi/Confluent operator) running as StatefulSet/CRDs; operators handle rolling restarts and partition rebalancing.

Storage provisioning:- Prefer dynamic provisioning with CSI-backed StorageClasses (gp3/io1/azuredisk/ssd) for PVCs.- Use separate StorageClasses: high-IO, general purpose. Set reclaimPolicy: Retain for critical DBs to avoid accidental deletion.- Enable VolumeSnapshot CSI for point-in-time backups; schedule backups externally (Velero + snapshots).- For Kafka, use provisioned disks with throughput guarantees and avoid network storage if latency-sensitive.

Availability & upgrade strategy:- For cluster control-plane: use managed provider for zero-downtime upgrades where possible.- Node upgrades: cordon + drain with PodDisruptionBudgets (PDBs) for apps; use rolling update on node pool (maxUnavailable=1 per AZ).- Stateful upgrades: rely on operators/StatefulSet rollingUpdate with partitioning; upgrade single replica at a time, verify replication health, then proceed.- Application upgrades: use Canary or Blue/Green for critical APIs. For stateless, rolling deployments with readiness/liveness probes.- Pre-upgrade checklist: automated integration tests, schema migration strategy (backward-compatible), backups verified, monitoring/alerts active.- Post-upgrade: smoke tests, metrics check, fallback plan (restore snapshot, rollback helm).

Observability & safety:- Centralized logging (ELK/Fluent Bit), metrics (Prometheus/Grafana), tracing.- Alerting on resource saturation, broker replica lag, DB replication lag.- IAM/Network segmentation, RBAC least privilege, image scanning.

Trade-offs:- Dedicated stateful nodes increase cost but reduce noisy-neighbor and improve performance.- Dynamic storage simplifies ops; static may be needed for legacy environments.

This strategy balances reliability, performance, and operational simplicity while minimizing downtime through careful use of node pools, operators, PDBs, autoscaling, and staged upgrades.

HardTechnical

45 practiced

Design a horizontally scalable Postgres-based architecture for a write-heavy workload where writes cannot be easily sharded and low write latency is a requirement. Evaluate options including leader-follower with replicas, managed distributed SQL (e.g., CockroachDB), and sharding approaches. Recommend an approach and justify trade-offs around latency, consistency, operational effort, and cost.

Sample Answer

Clarify requirements and constraints- Write-heavy workload where writes cannot be easily sharded- Low write latency is critical (sub-50–200ms depending on SLA)- Strong consistency likely needed for many write workloads- Prefer Postgres ecosystem if possible (compatibility, tooling)

Options evaluated (summary + trade-offs)

1) Leader-follower Postgres (single writable primary + replicas)- Description: One primary accepts all writes; synchronous or asynchronous replicas for HA/reads.- Latency: Lowest local-write latency when primary is co-located with app. Synchronous replication to local standby adds small commit latency; async gives fastest commits but risk of data loss on primary failure.- Consistency: Strong single-node consistency; replicas eventually consistent (unless sync).- Operational effort: Moderate — standard Postgres ops, backups, failover orchestration (Patroni/RepMgr).- Cost: Moderate; extra nodes for replicas and HA.- Suitability: Best when writes can't be sharded and you can scale vertically and optimize the single primary (bigger instance, fast disks, tuning).

2) Managed distributed SQL (CockroachDB, Yugabyte, Google Spanner-like)- Description: Multi-node, strongly-consistent distributed SQL with distributed transactions and multi-primary write capability.- Latency: Higher write latencies due to distributed consensus (Raft/Paxos) across replicas; can be mitigated by geo-local placement and locality-aware replicas but still > single-node local commit.- Consistency: Strong consistency and multi-node fault tolerance.- Operational effort: Higher initially (learning curve) but managed offerings reduce ops. Migration differences from Postgres (compatibility varies).- Cost: Potentially higher due to more nodes and cross-node replication overhead.- Suitability: Good if you need horizontal write scaling, geographic distribution, and strong transactional semantics across nodes.

3) Sharding (application-level or Citus)- Description: Partition data across many Postgres nodes by key (Citus as Postgres extension can distribute tables).- Latency: If writes are well-distributed by shard key, write latency per shard is low; if writes cannot be sharded, hotspots occur and latency suffers.- Consistency: Each shard is consistent; cross-shard transactions are more expensive or emulated.- Operational effort: High — design shard key, rebalancing, cross-shard joins/transactions complexity.- Cost: Efficient at scale when sharding works; expensive when re-sharding or hotspot handling required.- Suitability: Not ideal when writes cannot be partitioned by a reliable key.

RecommendationGiven "writes cannot be easily sharded" and "low write latency" priority, recommend a pragmatic two-phase approach:

Phase A — Single writable Postgres primary with HA and optimized write pipeline- Use a beefy primary (NVMe, high CPU), tuned Postgres (wal settings, checkpoint tuning, connection pooling), and colocate app and DB within same AZ.- Use synchronous replication to a local standby for failover if minimal data-loss is required; add asynchronous replicas for read-scaling.- Add write-side optimizations: batching, idempotent writes, bulk endpoints, use WAL-based async consumers for analytics.- Use connection pooling (PgBouncer) and partition hot tables by time or logical segments where possible to reduce contention.

Phase B — If growth outstrips single-primary capacity or availability/geo requirements mandate horizontal write scaling, migrate to a distributed SQL or hybrid model- Evaluate managed distributed SQL (CockroachDB or Yugabyte Cloud) for true horizontal write scaling and transactional semantics. Expect higher per-write latency due to consensus; benchmark with your workload profile.- Alternatively, adopt a hybrid: keep Postgres primary for low-latency critical writes and offload non-critical or aggregated writes to a distributed store or queue (Kafka + downstream writers), or selectively shard the heaviest hot paths into Citus or application-level partitions.

Justification of trade-offs- Latency: Single primary gives best local write latency. Distributed SQL introduces coordination latency; sharding reduces per-node latency only if writes are shardable.- Consistency: Single primary ensures strong consistency. Distributed SQL also provides strong consistency but at higher latency. Async replicas risk data loss.- Operational effort: Single primary + HA is lowest friction if team knows Postgres. Distributed SQL has higher operational and migration complexity but reduces manual sharding and can scale writes horizontally. Sharding requires substantial application changes and ongoing rebalancing.- Cost: Single-primary scales vertically (costly at high sizes) but simpler. Distributed SQL and many shards increase infrastructure and network cost.

Final recommendation (Solutions Architect stance)Start with a highly-optimized single writable Postgres primary with local synchronous standby for HA, plus asynchronous replicas for reads, while aggressively optimizing write paths (batching, pooling, WAL tuning) and adding observability. This minimizes write latency and leverages Postgres operational familiarity. Simultaneously run short POCs with managed distributed SQL to benchmark real workload latency/throughput and validate migration effort. If POCs show distributed SQL meets latency SLA and growth requires horizontal writes, plan staged migration to distributed SQL (or selective sharding for specific hot workloads) with careful cutover and fallback strategies.

EasyTechnical

54 practiced

Explain the role of a CDN in reducing latency and offloading origin servers. When would you pair a CDN with a global load balancer, and what are key considerations for cache-control headers, geo-routing, and dynamic content that should not be cached?

EasyTechnical

74 practiced

Compare blue-green and canary deployment patterns. Describe the operational steps for each, when one is preferable over the other, how rollback is handled, and the cost and complexity implications for a SaaS product serving 10k transactions per second.

Sample Answer

Blue-green vs Canary — concise comparison, operational steps, when to use, rollback, cost/complexity for a SaaS at 10k TPS.

Summary:- Blue-green: two full production environments (Blue = current, Green = new). Traffic flips atomically to Green when ready.- Canary: progressive rollout of new version to a small subset of traffic (canaries) then ramp to 100% based on metrics.

Operational steps

Blue-green:1. Build & deploy new release to idle Green environment identical to Blue.2. Run smoke, integration, and load tests against Green.3. Switch router/load-balancer (DNS or LB) from Blue to Green (atomic or staged).4. Monitor key metrics (latency, errors, business KPIs) for a short period.5. If stable, decommission Blue or keep as hot standby.

Canary:1. Deploy new version to small pool (1-5%) of instances.2. Route limited traffic (via feature flag or LB weights).3. Monitor detailed metrics, error budgets, user experience signals.4. Incrementally increase percentage (5%, 25%, 50%, 100%) with time and checks.5. Roll forward or stop depending on signals.

When preferable- Blue-green: good for simple, low-risk flips, fast rollback requirements, and when you can afford duplicate capacity and near-atomic cutover. Favored for simple state-less services or when database migrations are backward/forward compatible.- Canary: preferred for complex, stateful, high-risk services, gradual validation, heterogeneous customer impact, or when you need user-segment testing and observability-driven rollout.

Rollback handling- Blue-green: rollback is trivial and fast — flip LB/DNS back to Blue (seconds to minutes). Ensure session affinity and DB schema compatibility or use read-only/feature flags.- Canary: rollback involves reducing canary weight to 0 and draining canary instances; easier to limit blast radius but requires safe rollback code paths and feature flags for DB schema or behavior toggles.

Cost & complexity for 10k TPS SaaS- Blue-green: higher steady cost because you maintain duplicate capacity to handle peak traffic (approx. 2x infra during deployment windows). Simpler orchestration and easier rollback; less operational overhead.- Canary: lower duplicated capacity (only small canary pool) so cheaper during rollout, but requires sophisticated traffic routing, observability, automated gating, and more complex deployment pipelines and safety checks. At 10k TPS, canaries need careful capacity planning to ensure canary nodes see representative traffic patterns; instrumentation and automated analysis are critical.

Recommendation as Solutions Architect:- If speed of rollback and simplicity matter and budget allows, use blue-green for major releases that are backward-compatible and services that are mostly stateless.- For high-risk changes (behavioral changes, complex DB migrations, multi-tenant impacts) or when minimizing impact to customers is primary, use canary with automated health gates and feature flags.- Hybrid: use blue-green for infra-level changes and canary for code-path changes; always design DB migrations and feature toggles to be rollback-friendly.

MediumBehavioral

58 practiced

Tell me about a time when you had to convince a skeptical client or internal stakeholder to adopt a technical architecture change that increased short-term cost but reduced long-term risk. Use the STAR method: describe the Situation, Task, Actions you took, and the Results. Emphasize how you gathered evidence, presented trade-offs, and measured outcomes.

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.