Implement Proposal P first, since application-level caching addresses the database bottleneck and is the lower-effort change to deploy and validate.

Implement Proposal Q first, since adding a region addresses both causes simultaneously by placing a read replica near the customers and reducing primary load.

Implement neither proposal, since the two causes interact in ways that make individual interventions ineffective for any application of this kind.

Implement both proposals at the same time, since each addresses a different cause and the combined effect must be evaluated together rather than separately.

Single-region database with no caching of balances at all, since any cache layer is fundamentally incompatible with the requirement that balance values be exactly current.

Replicated database with an aggressive write-back cache for balances, because faster writes will improve the user experience even if the cache occasionally lags behind the database.

Replicated database with a long TTL cache on balance values, because long TTLs maximize the cache hit rate and reduce overall energy consumption across the system.

Single-region database with write-through caching for balance values, and routing of all balance reads to the primary database itself rather than to any read replica that might lag behind it.

Region Z, because the lowest cost should be the deciding factor whenever budget is mentioned at all in the architectural context.

Region W, because latency is the most user-facing factor and lowest latency must always take priority over grid carbon intensity in interactive applications.

Region X, because the cleanest grid produces the largest emissions reduction and that benefit outweighs the latency penalty for any application type.

Region Y, because it offers an acceptable balance across latency and carbon intensity without the trade-offs that the other regions impose on either factor.

Reduce the metrics ingestion rate by sampling every tenth reading so that the existing relational database can keep up with the load.

Move the metrics data into a time-series database that suits the append-heavy timestamp workload, while keeping the catalogue and accounts in the existing relational database.

Move all three workloads (catalogue, accounts, metrics) into a single document database that handles every type of data within one engine.

Increase the size of the database server until the inserts and the catalogue queries both fit comfortably within the new capacity envelope.

Deploy across the domestic region and a foreign region with patient data excluded from the foreign region, since this preserves availability for the parts of the system that can legally span regions.

None of the three is acceptable, because no design that uses a cloud region can simultaneously satisfy the residency rule and the availability target under any circumstances.

Deploy across two foreign regions, because two-region availability outweighs the data residency constraint and the patient data can be handled separately on dedicated infrastructure outside any cloud region.

Deploy across the single domestic region with a documented manual recovery procedure, since regulatory compliance is binding and the availability target must yield to the legal constraint.

The application and the database are in different regions, since each connection setup would otherwise pay the cross-region latency cost.

The database server has very few CPU cores, since pooled connections share processing resources more efficiently than independent connections.

The application uses a document database rather than a relational database, since document databases handle pooled connections more efficiently.

The application makes only a small number of database queries per day, since each saved connection setup is a noticeable share of the total work.

Migrate the database to a completely different cloud provider whose network is documented as being faster between the two regions.

Convert the deployment from active-active back to active-passive so that all traffic flows through the region holding the database.

Disable the second region entirely until a closer database can be provisioned for that region in a future maintenance window.

Add a read replica of the database in the second region and route the second region's read queries to that local replica.

The cache layer has been incorrectly configured and is serving expired data to the application instead of fetching fresh values.

The replicas have lost their connection to the primary and are serving data from the last successful synchronization point in time.

The application is sending writes to the replicas, which silently discard them rather than forwarding the writes to the primary.

The user's read landed on a replica that had not yet received the most recent change from the primary because of replication lag.

Streaming protocols are inherently latency-tolerant, and the location of the origin server has no observable effect on the user experience for any video service.

The CDN serves the bulk of user requests from edge caches, so most user-perceived latency depends on the edge rather than the origin's distance.

The origin region's cleaner grid produces electricity that travels directly to the edge nodes through the CDN provider's private network.

Modern streaming uses adaptive bitrate, which automatically compensates for any latency between the origin server and the end user.

Read-through caching is the only design pattern that can scale to thousands of writes per second on a typical relational database server.

Write-back caching would consistently produce more accurate counter values than write-through across the platform under heavy load.

Write-through caching cannot be used for counter values, because counters require atomic increment operations that the cache cannot guarantee under any production conditions.

The strict consistency that write-through enforces is unnecessary here and the database write on every update wastes energy.