Growth is the moment architecture stops being theoretical. A system that runs comfortably for a few thousand users can behave very differently once traffic multiplies, data accumulates and more teams deploy into the same environment. Scaling multiplies whatever is already there: efficiency and waste, resilience and fragility.
This review is designed to be run before a major launch, a regional expansion or a period of rapid growth. It examines cost and reliability together, because in the cloud they are two sides of the same set of decisions.
1. Define what “reliable” means for this system
- Set service level objectives for each critical user journey (signing in, checking out, submitting a request), covering availability and latency, rather than one uptime figure for the whole platform.
- Agree on an error budget, so the trade-off between delivery speed and stability is a shared, explicit decision.
- Define recovery time and recovery point objectives (RTO and RPO) for each data store, and confirm the architecture can actually meet them.
- Map external dependencies (payment gateways, SMS providers, identity services) and decide how the system behaves when each one fails.
2. Cost visibility before cost optimization
You cannot optimize what you cannot attribute. Before cutting anything, make spending legible.
- Enforce a tagging standard (owner, environment, product, cost center) through policy, not goodwill.
- Set budgets and anomaly alerts per environment and per team.
- Track unit economics: cost per transaction, per active customer or per tenant. A rising bill is fine if unit cost is falling; a flat bill with declining usage is not.
- Share cost reports with the teams that generate the spend, so engineering decisions carry their financial context.
3. Compute: right-size first, commit second
- Right-size instances and containers from observed utilization, not launch-day estimates.
- Configure autoscaling with sensible minimums and maximums, and verify that it scales down as well as up.
- Shut down development and staging environments outside working hours, or scale them to zero where the platform allows.
- Buy commitment-based discounts only once usage patterns stabilize; committing to an oversized baseline locks in waste.
- Use spot or preemptible capacity for interruptible workloads such as batch processing and CI runners.
4. Data: the quiet cost center
- Apply storage lifecycle policies that move aging data to cheaper tiers and delete what retention rules no longer require.
- Review snapshot and backup retention; orphaned snapshots accumulate silently.
- Examine data transfer: internet egress, cross-zone and cross-region traffic, and chatty service-to-service calls.
- Control observability spend: log volume, high-cardinality metrics and trace sampling can grow faster than the application itself.
- Consider caching and read replicas before scaling a primary database vertically.
5. Reliability architecture
- Run stateful components across multiple availability zones, and look for hidden single points of failure such as a lone NAT gateway or message broker.
- Put a timeout on every network call, retry with exponential backoff and jitter, and use circuit breakers to stop failures from cascading.
- Make operations idempotent, so retries cannot create duplicate orders or payments.
- Use queues to absorb bursts instead of sizing everything for peak load.
- Design for graceful degradation: when a non-critical dependency fails, the core journey should keep working.
6. Operational readiness
- Manage all infrastructure as code, using a tool such as Terraform or OpenTofu, with no manual changes in production.
- Instrument metrics, logs and traces against a consistent standard such as OpenTelemetry.
- Alert on what users feel, such as error rates and latency against objectives, not only on CPU and memory.
- Maintain runbooks for the most likely failures, and a clear on-call rotation with defined escalation paths.
- Load-test at expected peak plus a safety margin, and run game days that rehearse realistic failure scenarios.
7. Data residency and regulatory placement
For organizations operating in Saudi Arabia, where data lives is an architectural decision, not only a procurement one. Sector regulators and the National Cybersecurity Authority’s frameworks may shape what can be hosted where, and in-Kingdom hosting options are available from both local and global providers. Confirm early that every managed service your design depends on is available in the region you need. Treat this as general guidance, not legal advice.
Signals that this review is overdue
- The cloud bill grows faster than usage, and nobody can explain its largest lines.
- The same kinds of incidents keep recurring, and each one is fixed by hand.
- Teams hesitate to deploy on certain days, or only one person truly understands how production works.
- Staging no longer resembles production, so tests have stopped predicting real behavior.
Running the review
In practice, the review works best as a structured workshop bringing together engineering, product and finance, followed by a short period of evidence gathering: dashboards, bills, architecture diagrams and incident history. The output is a prioritized register of risks and savings opportunities, each with an owner, an effort estimate and a clear next step.
Optimize for cost per unit of value, not for the smallest bill.