Architecture Trade Offs and Cost Analysis Questions
Covers making and communicating architecture and technology decisions that balance trade offs across cost, performance, reliability, speed to market, and organizational complexity, for any kind of technical or tooling investment (cloud infrastructure, build versus buy, software licensing, platform consolidation, staffing and process changes). Topics include comparing competing approaches or vendors, estimating and explaining costs (licensing, implementation, maintenance, ongoing operational costs, and one-time transition costs), and understanding how those costs scale with usage, scale, or headcount. Includes business driven framing of technical decisions: capital expenditure versus operational expenditure, return on investment analysis, and Total Cost of Ownership. Candidates should be able to perform rough cost estimation, describe general cost optimization strategies (eliminating waste, right-sizing resources to actual demand, consolidating redundant tools or vendors, and weighing build versus buy or managed versus self-run alternatives), and explicitly articulate constraints and trade offs when prioritizing features, timelines, and resources. Cloud infrastructure costing (compute, storage, data transfer, reserved versus on-demand pricing) is one common example domain but not the only one this topic covers.
HardTechnical
95 practiced
You receive a cloud bill breakdown where compute is 60%, storage 20%, network 15%, and managed services 5% of the spend. Propose a prioritized optimization plan that targets the largest buckets first. For each proposed action (e.g., rightsizing, storage tiering, egress reduction, negotiating committed discounts), provide expected savings range, implementation effort, and risks/trade-offs.
Sample Answer
High-level priority (by spend): 1) Compute (60%) 2) Storage (20%) 3) Network (15%) 4) Managed services (5%). For each bucket I propose concrete actions with expected savings, effort, and risks.1) Compute — Rightsizing + instance family mix + committed/spot- Actions: run utilization analysis, downsize/convert underutilized VMs, move steady-state workloads to reserved/committed instances or savings plans, adopt spot for fault-tolerant batch jobs, use autoscaling and instance family modernization (Graviton/AMD).- Expected savings: 20–45% (rightsizing 10–25%, commitments 15–30%, spot adds incremental 5–15% for eligible workloads).- Effort: Medium — requires telemetry collection (CloudWatch/Stackdriver), analysis, testing, and deployment automation (weeks to 2 months).- Risks/trade-offs: performance regressions if undersized; operational complexity managing commitments and spot interruptions; migration/testing overhead.2) Storage — Tiering + lifecycle policies + dedupe/compression- Actions: classify data, move infrequently accessed data to cold/archival tiers, enable lifecycle policies, enable compression/deduplication for block/file stores, delete orphaned snapshots.- Expected savings: 15–50% on storage costs (depends on current hot-data ratio; typical 20–35%).- Effort: Low–Medium — policy work and verification, possible app changes for retrieval patterns (1–6 weeks).- Risks/trade-offs: retrieval latency/cost for cold tiers; potential restore complexity; ensure compliance/retention policies respected.3) Network — Egress reduction + optimized topology- Actions: identify cross-AZ/region egress, consolidate services into same region/VPC, use CDN for public content, cache responses, negotiate better data-transfer pricing or use peering/direct connect.- Expected savings: 10–40% of network spend (often high variance; CDN/peering can cut large egress costs).- Effort: Medium — architecture changes, CDN/caching setup, potential infra rework (2–8 weeks).- Risks/trade-offs: complexity in architecture, possible latency changes, CDN/vendor fees; need to validate data sovereignty.4) Managed Services — Rightsize usage + negotiate contracts- Actions: review managed DB sizes/RU limits, move to serverless/auto-scaling managed tiers where applicable, eliminate unused managed instances, negotiate enterprise discounts or committed usage for managed services.- Expected savings: 10–30% (depends on negotiating leverage and right-sizing).- Effort: Low–Medium — audit and contract negotiation (2–6 weeks).- Risks/trade-offs: vendor lock-in, potential loss of flexibility; changes may require schema/config updates.Cross-cutting recommendations- Implement continuous FinOps: tagging, cost allocation, alerts for anomalies (low effort, high ROI).- Pilot program: run small pilots (compute rightsizing + storage tiering) to validate savings before large rollout.- Governance: define SLA/performance guardrails to avoid over-optimization that harms business needs.This prioritized plan focuses first on compute (largest impact), then storage and network, balancing expected savings against implementation effort and risk.
HardTechnical
76 practiced
A microservice depends on a third-party SaaS API that charges per request. Traffic is growing and third-party costs are becoming significant. Propose architectural patterns to reduce per-request third-party charges while maintaining data freshness and compliance: consider caching, batching, pre-fetching, local fallbacks, and circuit-breaker strategies. For each pattern estimate its expected impact on third-party spend.
Sample Answer
Start by clarifying SLAs and compliance constraints (max acceptable data staleness, PII rules, regional data residency) — these drive which patterns are allowed and their parameterization.1) Caching (edge + local in-memory + persistent)- What: Cache responses at CDN/edge for public data, in-process LRU for hot keys, and a durable cache (Redis) for larger TTLs.- Freshness: use TTL tuned by SLA; implement stale-while-revalidate and conditional GET (ETag/If-Modified-Since).- Compliance: encrypt-at-rest, separate caches per region/tenant if required.- Expected spend impact: 40–70% reduction for read-heavy APIs (hot key hit rates).2) Request coalescing & batching- What: Aggregate many small client requests into one batched call to the SaaS (server-side queue + periodic flush or size-based flush). Coalesce concurrent identical requests to a single inflight request (singleflight).- Freshness: micro-batching (10–200ms) gives near-real-time; larger windows increase savings but add latency.- Impact: 20–60% reduction depending on request fan-out and ability to batch.3) Pre-fetching (predictive)- What: On user/session signals, pre-warm cache with likely-needed records (background workers or edge prefetch).- Freshness/compliance: only prefetch non-sensitive data or respect consent flags.- Impact: 10–30% additional reduction for predictable access patterns.4) Local fallbacks / degraded mode- What: Serve best-known cached snapshot or synthetic fallback when third-party unavailable or to avoid calls for non-critical flows.- Freshness: document staleness tolerance per workflow; mark responses as "cached" in UI.- Compliance: ensure read-only cached copies meet retention/consent.- Impact: 5–20% incremental savings and resilience improvement.5) Circuit breaker + adaptive throttling- What: Rate-limit/circuit-breaker that trips on errors/latency to protect cost and availability; use progressively increased cooldowns and slow-start recovery.- Behavioral policy: fallback to cache, reduce polling frequency, or queue requests during open state.- Impact: prevents cost spikes and can reduce spend by 15–50% during failure/backoff windows.Combined architecture and orchestration- Flow: Client → API Gateway (rate-limit, auth, edge cache) → Service (local cache, singleflight, batcher) → Background workers (prefetch, refresh) → SaaS API.- Observability: track hit-rate, cost-per-req, freshness metrics; implement alerts for cache-thrashing and cost anomalies.- Security & Compliance: encryption in transit+rest, per-tenant isolation, audit logs, TTLs compliant with retention policies, support for on-demand purge.Estimated combined impact: 60–95% reduction in third-party spend depending on workload shape (read-heavy, high fan-out benefits most). Trade-offs: added system complexity, possible increased latency for writes, coordination overhead, and need for careful testing of staleness/consent rules. Prioritize implementations by ROI: start with caching + singleflight + monitoring, then add batching and prefetching, finally circuit-breaker and advanced fallbacks.
EasyTechnical
88 practiced
Explain the difference between an SLA and an SLO and how these service targets influence architecture and cost. Give two concrete examples of how moving from a 99.9% SLO to a 99.99% SLO changes system design (components to add) and the kinds of cost increases you would expect.
Sample Answer
SLA vs SLO (short):- SLO (Service Level Objective) is an internal, measurable reliability target for a service (e.g., 99.9% availability over a month). It drives engineering goals and runbooks.- SLA (Service Level Agreement) is a contractual promise to the customer, often backed by penalties or credits. SLAs are typically derived from SLOs but add legal/financial consequences and reporting obligations.How targets influence architecture and cost:- Higher SLOs demand more redundancy, faster detection and recovery, and more testing/observability — all of which increase complexity and cost.- They shift design trade-offs from “cheaper/single-fault-tolerant” to “defense-in-depth, fail-safe” architectures and more operational effort.Two concrete examples moving from 99.9% → 99.99% (10× tighter downtime budget):1) Public-facing web application- Components to add: multi-AZ → multi-region active-active deployment, global load balancer (DNS failover), cross-region data replication (read replicas + conflict resolution), automated health checks and traffic failover, more aggressive CDN + origin shielding, runbooks and automated rollback.- Cost impact: infrastructure costs often increase ~2–3× (extra regions, cross-region networking, replicated VMs/containers, higher CDN egress). Operational costs +20–50% for runbook automation, DR rehearsals, and increased monitoring/alerting.2) Transactional database (strong consistency)- Components to add: synchronous or semi-synchronous replication with quorum across regions, distributed consensus (e.g., Paxos/Raft), multi-master or leader-failover automation, faster backups and point-in-time recovery, more frequent integrity checks.- Cost impact: storage and compute for replicas increase ~2–4×; networking costs for replication rise; engineering/DBA effort rises significantly (30–100%) because low-latency cross-region consistency is hard and needs careful tuning and testing.Notes on trade-offs:- Improvements yield diminishing returns: each extra “nine” typically costs disproportionately more.- Consider whether SLA requires 99.99% (contract) or an internal SLO is sufficient — sometimes compensating with business measures (grace periods, degraded mode) is cheaper than full replication.- Always quantify customer impact vs cost and present options (e.g., 99.9% single-region standard, 99.99% premium multi-region offering).
MediumTechnical
76 practiced
You're advising the sales team on pricing for a PaaS offering. How do architectural decisions (single-tenant isolated instances vs shared multi-tenant architecture) impact operational cost, reliability, and pricing tiers? Propose a tier structure (e.g., basic, standard, premium) with the architectural differences and corresponding cost drivers for each tier.
Sample Answer
Start by mapping architectural choices to the primary cost & reliability axes customers care about: compute/isolation cost, operational complexity, reliability/SLA, security/compliance, upgrade/maintenance effort.Tier proposal (3 commercial tiers + enterprise option)1) Basic — Shared multi-tenant (single cluster, logical tenant separation)- Architecture: Shared app/runtime and DB schemas or row-level tenant IDs.- Cost drivers: amortized compute/storage, lower per-tenant infra cost, simpler backups, lower ops overhead.- Reliability/SLAs: Best-effort (e.g., 99.5%), noisy-neighbor risk mitigated by quotas and autoscaling.- Pricing signals: seats, monthly active users, storage GB, API calls.2) Standard — Pooled multi-tenant with stronger isolation (namespace-per-tenant, resource quotas, dedicated DB instances per group)- Architecture: Shared cluster with per-tenant namespaces, separate DB instances or schemas for larger tenants.- Cost drivers: more compute & DB instances, enhanced monitoring, per-tenant backups, patch coordination.- Reliability/SLAs: Higher (e.g., 99.9%), reduced noisy-neighbor effects.- Pricing signals: vCPU/RAM quotas, storage, request volumes, SLA premium.3) Premium — Single-tenant isolated instances (dedicated VM/K8s namespace + dedicated DB)- Architecture: Fully isolated runtime and datastore per customer; optional VPC peering or private network.- Cost drivers: dedicated infra, per-tenant deployments, patching/upgrade windows, bespoke monitoring/backup, higher support and compliance costs.- Reliability/SLAs: 99.95%+, predictable performance, easier compliance (PCI/HIPAA).- Pricing signals: baseline instance fee (covers reserved infra), usage-based components (IOPS, egress), higher onboarding & support fees.Enterprise (optional): On-prem or customer VPC deployment, premium engineering support, custom SLAs — priced for migration, sustained support, and integration.How to translate to pricing:- Base subscription covers platform access; add tier multiplier for isolation level.- Usage add-ons: vCPU-hours, storage GB, IOPS, data egress, API RPS, number of DB instances.- Support & SLA addons: faster response, dedicated CSM, custom patch windows.- Include one-time onboarding/customization fees for Premium/Enterprise.Operational impacts to communicate to sales:- Multi-tenant = low unit cost, fast provisioning, but constrained for high-compliance customers.- Single-tenant = higher predictable cost, simpler performance isolation, more ops work (deployments, backups, upgrades).- Use concrete pricing levers (instance fee + usage) and SLAs to justify margins and meet customer risk/compliance needs.
HardSystem Design
64 practiced
Design a cost-effective logging and observability pipeline for a microservices platform with ~200 services producing 10 GB/day of logs. Consider ingestion, real-time alerting, long-term storage (hot/warm/cold), indexing/query costs, retention policies, and sampling. Present at least two architecture options (managed observability vs self-hosted ELK-like) with estimated monthly cost buckets and trade-offs.
Sample Answer
Requirements & constraints:- ~200 microservices, 10 GB/day logs (~300 GB/month raw). Need real-time alerting, searchable recent logs (hot), cheaper long-term storage with occasional queries (warm/cold), retention policies, index costs minimized, predictable monthly pricing, secure multi-tenant isolation.Option A — Managed observability (e.g., Datadog/Elastic Cloud/Logs Ingestion + S3 lifecycle + Grafana Cloud)High-level:- Agents (Fluent Bit) on hosts/k8s -> send structured logs to managed ingest endpoint.- Real-time ingestion + streaming into managed indexing for hot window (7–14 days).- Archive raw logs to S3 (or provider’s cold storage) with lifecycle: hot (0–14d indexed), warm (14–90d limited index/partial), cold (90–365d gzipped, queryable via S3/Glacier).- Alerts via provider’s metrics/log alerts + Pager/Slack.Costs (monthly, rough for 300 GB/month):- Log ingestion & short-term indexing: $600–1,200- Cold storage (S3 IA / Glacier for 200 GB x months): $5–30- Alerting & dashboards: $100–300Total: ~$700–1,500/monthTrade-offs:- Pros: fast time-to-value, SLA, maintenance-free, integrated alerting, scaling handled.- Cons: higher per-GB indexing cost, less control over retention mechanics, vendor lock, pricier for high query volumes.Option B — Self-hosted ELK-like (Fluent Bit -> Kafka -> Elasticsearch/OpenSearch + MinIO/S3)High-level:- Fluent Bit -> Kafka (buffering) -> Logstash/consumer -> OpenSearch cluster for hot indexed data (7–14d).- Raw log archive to MinIO (S3-compatible) with lifecycle to object storage / Glacier-equivalent.- Use query acceleration (OpenSearch cold nodes or ILM: roll indices, freeze/unfreeze) and rollups.- Alerting: ElastAlert/Opensearch alerts + Prometheus/Grafana for metrics.Costs (monthly, infra + ops for 300 GB/month):- Compute (k8s nodes for OpenSearch master/data/cold) + Kafka: ~$800–1,200- Storage: 1 TB hot SSD for indices ~$100; object storage 300 GB ~$10–30- Ops (engineering time/managed backups/security): allocate ~$1,500–3,000 (or equivalent headcount)Total: ~$2,400–4,500/month (lower if on reserved infra or smaller ops)Trade-offs:- Pros: lower long-term index cost per GB, full control (schemas, retention, encryption), no vendor lock.- Cons: operational complexity, scaling and reliability responsibility, higher initial setup and ongoing ops.Common design decisions & optimizations:- Sampling: sample verbose debug logs (e.g., 1–10%) and keep full logs on error traces; use dynamic sampling based on rate and severity.- Indexing policy: ingest structured JSON, index essential fields, store full message in object storage; use partial indexing (only metadata) for older data.- Retention: Hot indexed 7–14 days; warm 14–90 days (reduced indices, less replicas); cold 90–365 days compressed in object storage with on-demand restore.- Cost controls: rate-limiting, caps per service, alert on ingestion spikes, per-team budgets and quotas.- Security & compliance: encrypt in transit/at rest, RBAC, audit logs.Recommendation:- For rapid delivery, minimal ops and predictable costs: choose managed (Option A) with strict sampling & lifecycle rules to control indexing cost.- For customers with cost sensitivity at scale, strict compliance, or desire for long-term lower TCO and full control: choose self-hosted (Option B) and invest in automation (ILM, autoscaling, backups).
Unlock Full Question Bank
Get access to hundreds of Architecture Trade Offs and Cost Analysis interview questions and detailed answers.
