Define recovery before choosing services
Agree how much data loss and downtime the business can tolerate. Identify which user journeys matter most and what evidence will show that they are working. Availability and disaster recovery solve related but different problems.
Choose boundaries that match the workload
Separate public entry points, application processing, and data responsibilities. Decide which components need independent capacity and which can stay together. Managed services can reduce maintenance work, but their limits, costs, and failure behavior still need review.
Example: isolate a slow reporting workload
Suppose a dashboard shares a database with a heavy daily report. Adding servers to the dashboard may not resolve database contention. An asynchronous reporting job, a queue, or a separate read model may protect interactive requests. Validate the decision with workload measurements rather than assuming the split will help.
Make recovery an executable procedure
Keep environment definitions versioned and document dependencies needed for restoration. A backup is useful only when operators can restore it within the agreed recovery window. Exercise recovery in a controlled environment and record the observed result.
Questions for an architecture review
Who owns an alert? What happens when a dependency times out? Can a deployment be rolled back? What is the cost of idle capacity? Keep answers with the architecture so that future changes can be evaluated against the same requirements.