MediumTechnical

135 practiced

You must plan a data migration requirement: 'Move customer records (50M rows) to a new system without losing historical audit fields.' Outline your high-level decomposition: extraction, transform, load phases, verification steps, performance constraints, and rollback approach. Keep the answer concise but actionable.

Sample Answer

Situation: Move 50M customer rows to a new system while preserving all historical audit fields (created_by, created_at, updated_by, updated_at, change_history, etc.). High-level, actionable decomposition:

Extraction- Inventory source schema + audit columns; capture referential links and soft-deletes.- Choose method: bulk export (snapshot) for static data + Change Data Capture (CDC) for ongoing changes during cutover.- Export formats: compressed Parquet/ORC or CSV with lossless types; include source row IDs and version tokens.- Secure, staged export to intermediate storage (S3/GCS/Azure Blob) with encryption and manifest files.

Transform- Schema mapping document (field mappings, type conversions, null-handling). Keep audit fields immutable — map 1:1.- Apply deterministic transformations: timezone normalization, ID translation (GUID mapping table), canonicalize enums.- Compute and store checksums (row-level hash) and record lineage metadata (source_file, offset).- Validate transforms with sampling and automated unit tests (schema checks, referential integrity, checksum comparisons).

Load- Bulk-load into target (parallel writers, partitioning by customer_id hash) using native bulk-import APIs or dataflow engines (Spark/Dataflow).- Maintain original audit fields as system attributes or in a separate audit history table if target enforces system-generated metadata.- Apply CDC stream to catch changes since snapshot; reconcile with last snapshot using version/timestamp ordering.- Use idempotent upserts (MERGE) keyed by source row ID + version to avoid duplicates.

Verification- Row counts per partition, checksum equality, sample full-row diffs.- Referential integrity checks, unique constraints, and histogram/statistics comparisons.- Reconciliation report: rows migrated, mismatches, failed rows with error reasons.- Run end-to-end business validation (search, sample transactions) and have stakeholders sign off.

Performance constraints & ops- Target throughput: compute based on window (e.g., 50M rows / 8 hours ≈ 1,736 rows/sec) and plan headroom (2–5x).- Parallelism: tune partitions, batch sizes, network IO; use autoscaling workers.- Throttle to protect source RDBMS: schedule heavy exports off-peak; use replica for extraction if available.- Monitor latency, error rates, backpressure; alert on SLA breaches.

Rollback & cutover strategy- Non-destructive approach: keep source authoritative until verification complete.- Dual-write (if feasible) or read-from-source until a cutover timestamp.- Backout plan: stop new writes to target, revert routing to source, use stored manifests and idempotent deletes to remove partially loaded data (or restore target from point-in-time backup/snapshot).- Maintain immutable manifests and audit logs to reconstruct or re-run specific batches.- Dry-run, rehearsal on full-scale staging, and runbook with automated scripts for rollback steps and stakeholder communication.

This plan preserves audit history, minimizes source impact, provides verifiable integrity checks, and includes safe rollback and cutover paths.

EasyTechnical

80 practiced

Perform a high-level risk assessment based on the following business requirement: 'Migrate on-premises customer data and workflows to a managed cloud tenant with zero downtime during business hours.' List five principal risks, the potential impact for each, and one mitigation strategy per risk.

EasyTechnical

71 practiced

Explain what non-functional requirements (NFRs) are and provide five NFR examples that a solutions architect should extract from a client for a public-facing e-commerce platform (include measurable targets where possible).

HardSystem Design

98 practiced

A client requires an operations SLA of '99.99% uptime' for a core service. Decompose the requirement into architecture patterns (redundancy, failover), testing and validation activities (chaos testing, failover drills), and ongoing operational practices needed to meet this SLA. Quantify how much redundancy contributes to the SLA target.

Sample Answer

Requirements & constraints:- Target: 99.99% uptime = at most 52.56 minutes downtime/year.- Core service critical, likely strict RTO (minutes) and RPO (seconds/minutes). Assume multi-region legal/compliance constraints and client tolerance for cost.

High-level architecture patterns:- Active-active multi-AZ and multi-region deployment for the service front-end and stateless tiers; geo-load-balancer (DNS with health checks + anycast/GLB) to distribute traffic.- Stateful data: primary-replica + synchronous replication within region for durability + async cross-region replicas for DR. Use multi-master only if application supports conflict resolution.- Redundancy: N+1 at component level (app servers, DB replicas, message brokers), with autoscaling groups sized for capacity and surge headroom.- Circuit breakers, bulkheads, rate-limiting, and graceful degradation patterns to limit blast radius.

Failover & orchestration:- Automated health detection and orchestrated failover (leader election, DNS failover with low TTL, BGP/anycast where available).- Blue/green or canary deployments to avoid rollout-induced downtime.

Testing and validation:- Regular chaos engineering: AZ and region shutdowns, network partition, instance termination, degraded storage IOPS. Run in production-like environments and gradually in prod during low-risk windows.- Failover drills quarterly: simulate primary DB loss, perform RTO/RPO measurement and runbooks validation.- Chaos scenarios should be tied to SLIs/SLOs (availability, latency, error rate) and monitored automatically.- Automated test coverage: e2e synthetic probes, health checks, and recovery path unit/integration tests integrated into CI.

Operational practices:- 24/7 monitoring and alerts (PagerDuty), SLO/SLA dashboards, runbooks, playbooks.- Capacity planning, change management, pre-deployment validation, and postmortem blameless reviews.- Patch management with canary rollout and maintenance windows.- Regular backup verification and cross-region restore tests.- Continuous cost/availability trade-off reviews with client.

Quantifying redundancy contribution:- Availability multiplication model: if independent components have availabilities A, overall A_total = product(A_i). Example: assume: - Single AZ app tier: 99.95% -> add second AZ in active-active: combined availability ≈ 1 - (1-0.9995)^2 ≈ 99.999975% (practically eliminates AZ failure). - DB: primary synchronous within region ~99.99%; async cross-region adds protection for region failure; combined across region failover can raise perceived availability to ~99.995–99.999 depending on failover automation.- Realistic: engineering overhead, software bugs, and correlated failures reduce ideal math. For 99.99% target, design for >99.995% component-level and include operational practices; redundancy typically contributes the largest share (~70–90%) but must be paired with automation, testing, and ops to close the remaining gap.

Trade-offs:- Cost vs. availability: multi-region + synchronous replication and runbooks increase cost/complexity.- Complexity vs. recovery time: fully automated failover reduces human error but requires investment in testing and safe rollback.

Recommendation:- Propose active-active multi-AZ with automated failover, synthetic monitoring, quarterly failover drills, continuous chaos testing, and SLIs/SLOs tracking. Target component availabilities >99.995% to comfortably meet client 99.99% SLA after accounting for correlated risks.

HardSystem Design

103 practiced

A complex requirement includes multi-tenant isolation with per-tenant customizations and plugin hooks. Decompose the requirement into configuration model, tenancy boundaries, extension points, security implications, and CI/CD considerations for safely deploying tenant-specific code.

Sample Answer

Requirements decomposition for multi-tenant system with per-tenant customizations and plugin hooks:

Configuration model- Separate config layers: global defaults, tenant-profile (organization-wide), tenant-instance (environment), runtime overrides. Store declaratively (JSON/YAML) in a versioned config store (e.g., Git-backed config repo + Vault for secrets). Use schema validation (JSON Schema) and feature flags per tenant. Example: tenant A overrides payment provider and theme via tenant-profile file; runtime overrides through admin UI persisted to config store.

Tenancy boundaries- Logical isolation by default: single application codebase, per-tenant data partitioning (row-level with tenant_id + optional dedicated DB/schema for high-security tenants). Network/process isolation for high-risk tenants via separate containers or clusters. Authentication/authorization scoped by tenant context; enforce strong RBAC and tenancy-aware middleware to inject tenant_id into queries and sanitize access.

Extension points / plugin architecture- Define clear extension surface: request/response middleware hooks, event-driven plugins (pub/sub), extensible UI components. Use sandboxed plugin runtime (WebAssembly or constrained containers) with strict resource/time limits. Plugins register capability manifests; load order and dependency resolution controlled centrally. Provide stable plugin SDK and backward-compatibility guarantees.

Security implications- Threat model: data leakage across tenants, plugin privilege escalation, supply-chain risk. Mitigations: tenant-aware access controls, input validation, CSP and CORS for UI plugins, code signing for plugins, runtime sandboxing, secrets isolation (per-tenant keys in Vault), rigorous audit logging, periodic pentests, and SCA for plugin dependencies.

CI/CD considerations for safe tenant-specific code- Keep core platform CI/CD separate from tenant plugin delivery. Pipeline patterns: - Platform pipeline: run unit/integration tests, canary deploys to shared infra. - Plugin/tenant pipeline: gated promotion per-tenant; run plugin unit tests, contract tests against platform mock, security scans, and run in isolated staging tenant environment. Use feature flags and blue/green or shadowing to test tenant changes. Maintain automated rollback and tenancy-scoped monitoring/alerts. Enforce approval workflows for tenant-specific deployments (business owner + security).

Trade-offs- Dedicated DBs increase isolation but cost more. WASM sandboxing gives safety with performance trade-offs. Git-backed configs give auditability but require operational discipline.

Outcome- This decomposition balances flexibility (per-tenant customization) with safety (sandboxing, CI gates, data isolation) and operational scalability.

Requirements Analysis & Problem Decomposition Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank