Design for New Solutions

Decision frame

The best professional-level architecture is not the one with the most services. It is the option that meets all stated requirements with the least unnecessary operational burden and a credible failure model. Extract hard requirements before preferences: business outcome, users, data, compliance, availability, RTO, RPO, latency, throughput, security, integration, migration, operations, budget, timeline, and team capability.

Rank options by satisfied constraints and explicitly rejected alternatives. A technically possible design can still be wrong because it requires more custom operations, violates recovery objectives, creates a migration dead end, or costs more without business benefit.

Objective map

Objective	Required judgment	Proof
2.1 Design a deployment strategy	Select artifact, infrastructure, environment, rollout, validation, and rollback patterns	A failed release returns to a known-good image and configuration
2.2 Design business continuity	Convert BIA, dependencies, RTO, RPO, and data constraints into backup and DR	A timed recovery test meets business objectives and validates integrity
2.3 Determine security requirements	Embed identity, data, network, application, logging, compliance, and supply-chain controls	Threats and obligations map to implemented, testable controls
2.4 Design reliability	Remove single points, isolate faults, manage quotas, scale, recover, and test behavior	Component and dependency failures stay within the intended blast radius
2.5 Design for performance	Match compute, storage, database, network, integration, cache, and scale to measurements	Representative load meets latency and throughput objectives
2.6 Design for cost optimization	Model demand, elasticity, commitments, data movement, lifecycle, and operating cost	Cost per business unit remains within target without breaking other pillars

Deployment strategy

Make infrastructure and application releases versioned and repeatable. Separate build from deployment, protect artifact provenance, and scope deployment roles. Include schema, configuration, feature flags, secrets references, infrastructure, and rollback compatibility in the release design.

Rolling deployment limits extra capacity but mixes versions and can complicate rollback. Blue/green keeps an intact prior environment and supports controlled traffic shift at added temporary cost. Canary exposes a small share of traffic before expansion and requires representative metrics and safe routing. Immutable replacement reduces configuration drift. In-place change may be necessary for some stateful systems but carries higher recovery risk. Choose from failure cost, state compatibility, capacity, time, and observability.

Validate more than health. Check business transactions, security controls, dependency compatibility, latency, error rate, and data correctness. Database changes should be backward compatible across the rollout or use an expand-and-contract pattern. Keep rollback image and configuration and define triggers before deployment.

Business continuity and disaster recovery

Begin with business impact analysis. RTO is the maximum target time to restore the business capability; RPO is the acceptable data-loss window. Both are requirements, not properties automatically delivered by a service. Map people, identity, DNS, network, data, keys, secrets, artifacts, quotas, suppliers, and operating procedures.

Backup and restore minimizes steady-state cost but usually has the longest recovery. Pilot light maintains critical core components and data. Warm standby runs a reduced functional environment. Active/active can reduce interruption but adds consistency, routing, conflict, data, and operations complexity. Multi-site is not the answer when the business does not justify it or the application cannot reconcile state.

Use service-native backup, replication, snapshots, AWS Backup, cross-account vault controls, and cross-Region copies according to risk. Replication can copy corruption or deletion, so keep independent recovery points and protected retention. Test restores, application integrity, DNS or traffic changes, keys, permissions, quotas, and failback. A backup completion metric does not prove recoverability.

Security architecture

Apply the shared responsibility model and least privilege. Establish workforce and workload identity, account boundaries, network paths, encryption and key ownership, secrets, logging, detection, vulnerability management, incident response, and supply-chain controls. Use managed services to reduce undifferentiated operations when their control and service characteristics meet the requirement.

Threat-model public interfaces, administrative planes, data flows, cross-account trust, build pipelines, and third parties. Keep data authorization separate from network reachability. Use preventive controls for unacceptable outcomes, detective controls for drift and attacks, and recovery controls for assumed failure. Define evidence and owner for each major control.

Reliability and performance

Design for the documented behavior of dependencies. Use multiple Availability Zones for eligible regional workloads, health-based routing, horizontal scaling, queues for decoupling, idempotency for safe retries, and bounded timeouts. Avoid retry amplification. Use circuit breakers, backpressure, dead-letter handling, and graceful degradation where appropriate.

Identify state and consistency requirements. Choose relational, key-value, document, graph, time-series, cache, object, block, or file services based on access pattern, transactions, scale, latency, durability, and operations. Do not pick a database because it is labeled serverless or globally available. Model hot partitions, indexes, connection limits, write conflicts, replication lag, and recovery.

Performance optimization begins with workload characteristics. Measure request size, read/write ratio, object size, working set, concurrency, burst, locality, and tail latency. Caching reduces origin load but introduces freshness and invalidation decisions. Event-driven and asynchronous designs absorb bursts but change consistency and user feedback. Accelerators and content delivery help when network distance or repeated content is the constraint.

Cost optimization

Model steady, variable, and exceptional demand. Include compute, storage, requests, licenses, data transfer, NAT and endpoints, backups, logs, support, idle environments, and human operations. Use elasticity for variable demand, lifecycle policies for data, rightsizing from telemetry, and commitments only for stable measured usage. Managed services can cost more per unit but reduce staffing and failure burden.

Optimize across pillars. Removing redundancy may save money while violating availability. Compressing logs may reduce query value. Moving to a cheaper Region may violate latency or residency. The target is cost-effective fulfillment of requirements.

Decision patterns

Constraint	Strong pattern	Reject when
Fast rollback and material failure cost	Blue/green or immutable release	Temporary duplicate capacity is impossible
Bursty asynchronous work	Queue and horizontally scaled consumers	The business requires immediate synchronous completion
Near-zero RTO/RPO across Regions	Carefully justified active design	Application state and operations cannot support it
Long RTO and low steady cost	Backup and restore	Recovery time cannot meet the BIA
Repeated global read content	CDN or cache	Freshness and authorization cannot be preserved
Stable baseline usage	Savings Plans or reservations after measurement	Demand and ownership are uncertain

Scenario drill

A payment platform requires 99.99% availability, sub-200 ms reads, RPO under one minute, RTO under 30 minutes, auditable releases, and controlled cost.

Clarify consistency, write-region, transaction, residency, and peak-volume requirements.
Design Multi-AZ application and data layers with queues and idempotent processing.
Select a cross-Region data and recovery strategy that can actually meet RPO/RTO.
Protect identity, keys, secrets, data paths, build artifacts, and audit evidence.
Use canary or blue/green deployment with backward-compatible schema and business validation.
Load-test normal and failure modes, then run a timed recovery and failback exercise.
Model steady capacity, burst, data transfer, backups, logs, and operational cost.

Common traps

Choosing multi-Region before defining RTO, RPO, state, and business value.
Calling a system highly available because each component spans Availability Zones.
Using retries without deadlines, idempotency, or backpressure.
Selecting a data service without modeling access patterns and consistency.
Validating deployments only with HTTP health checks.
Assuming replication is a protected backup.
Reducing cost in a way that violates reliability, security, or performance requirements.

Self-check

Compare rolling, blue/green, canary, and immutable deployment for a stateful service.
Map one RTO/RPO pair to a DR pattern and timed test.
Choose a database from access pattern rather than product features.
Identify retry amplification in a three-service request chain.
Build a total-cost model that includes operations and data transfer.

Objective coverage

Design a deployment strategy

Design business continuity

Determine security requirements

Design reliability

Design for performance

Design for cost optimization