Match banking workloads to cloud, owned facilities and colocation. Explore latency, failure containment, degraded service and the economics of placement.
Workload placement is part of resilience architecture
The September colocation manual adds a physical and commercial layer to this platform argument. A data centre supplies a location, power, cooling, connectivity and operational services; a bank still owns the correctness and recovery behaviour of its workload. A second site does not create recovery capability if data, identity, telecommunications or operating procedures fail together.
Classify the workload before comparing providers. Latency-sensitive transaction processing, settlement, batch risk, archival retention and model training have different constraints. The acceptance criteria should specify tolerated disruption, tolerated data loss, recovery sequence, data location, security and required connectivity. A low rack price is irrelevant when the selected site cannot support the workload’s density or commissioning date.
The source emphasises the difference between announced capacity, contracted capacity, energised capacity and usable IT capacity. A development pipeline is not power the bank can consume today. Clarify whether quoted kilowatts describe committed power, actual IT draw or a facility rating; whether redundancy is included; and whether cooling supports the intended equipment under the contractual operating envelope. Power Usage Effectiveness is a ratio of total facility energy to IT energy, not a direct measure of application availability.
Compare the complete placement bill
The procurement model should include reserved power, energy treatment, racks or cages, cross-connects, network ports, remote hands, setup, migration, taxes and escalation. Separate fixed commitments from metered charges and test ramp-up assumptions. Reserving a large block early can reduce availability risk while creating stranded cost if deployment slips. Buying minimal capacity can preserve cash while leaving the next phase exposed to scarcity.
Retain the source’s scenario approach rather than quoting purported market-wide dollars per kilowatt. Compare offers on the same capacity, geography, resilience design and timing. Record who funds fit-out and who bears energy-price, currency and delay risks. A commercial commitment must be assessed alongside the ability to move or reduce a workload at renewal.
Prove failure independence and recovery
Physical diversity needs evidence at the level relevant to the service: independent power paths, network routes, operational access, common software dependencies and staff procedures. Two data-centre addresses alone do not prove independence. Recovery rehearsal should cover data consistency and operational authority as well as the ability to start a server. A payments service that is reachable but duplicates a transaction has failed its purpose.
ESMA’s current DORA overview identifies the EU regime’s application from 17 January 2025 and its focus on ICT risk, incident management, testing and third-party risk. This is a relevant current control context for in-scope entities, not a claim that every jurisdiction or workload has identical legal requirements. The practical architecture lesson is to connect third-party arrangements to the service, dependency map, test evidence and exit plan.
Run the placement decision through the same failure model as the application. Test loss of a site, degradation of a shared carrier, delayed equipment access and a recovery with stale data. The final buying output should be a workload-to-site decision, a complete cost bridge, a dependency register and an accepted recovery result. The colocation manual’s private call scripts, supplier relationships and unverified institutional-spend statements are excluded from this public adaptation.
Figure 01 · Conceptual framework
From banking workload to resilient placement
The operating architecture behind resilience
A resilient platform does not assume that every dependency responds quickly or that every request succeeds. It limits the damage of slow and failed components, preserves the correctness of important actions and gives operators a clear recovery path. This is especially important when a customer-facing transaction spans several services.
This reference report combines historical case studies of a large commerce platform and a global media platform. Company and product names have been removed. Reported scale and performance figures remain historical case claims, not independently validated service guarantees. The purpose is to extract transferable engineering principles while correcting overbroad claims about exactly-once processing and distributed-system behaviour.
Slow failure can be worse than immediate failure
A slow dependency occupies threads, connections and memory while other requests accumulate. If every caller waits for a long default timeout, a local problem can spread across the system. A timeout is therefore a capacity decision as well as a customer-experience decision.
The commerce case described moving away from 30–60 second defaults toward example settings around one second for connection establishment and five seconds for read/write operations. These are historical starting points from the source, not universal recommendations. The appropriate values depend on the service and the consequences of retrying.
Shorter timeouts need a controlled retry policy. Retrying immediately and repeatedly can amplify an outage. Use bounded attempts, backoff and jitter where appropriate, and distinguish operations that are safe to retry from those whose outcome is uncertain. For a payment, an uncertain response requires a status check and reconciliation, not blind repetition.
Circuit breakers and bulkheads limit propagation
A circuit breaker stops sending normal traffic to a dependency when failure crosses a defined condition, then allows controlled probes to establish recovery. A bulkhead limits the resources one dependency or workload can consume. Together they reduce the chance that one unhealthy service exhausts the whole platform.
The thresholds should follow observed behaviour and business priorities. A breaker that opens too aggressively can deny useful service; one that reacts too late can allow queues to overwhelm the system. Resource isolation can be applied by dependency, tenant, region or workload where those boundaries are operationally meaningful.
The media-platform case emphasised modular services with explicit ownership. Modularity can help contain failure, but it also creates more network boundaries. A large number of services is not itself resilience. The value comes from clear interfaces, bounded dependencies and teams that can diagnose and recover their components.
Capacity planning needs queueing discipline
Little’s Law relates the average number of items in a stable system, , to arrival rate and average time in the system, :
If service time rises while arrivals remain unchanged, the number of in-flight requests rises. This explains why tail latency can consume capacity even when average traffic appears manageable. The relationship applies under its stability assumptions; it is not a guarantee that an overloaded system will settle into a safe state.
The source case used approximately 30% headroom and workload throttling near an example 80% utilisation level. These are case-specific planning claims, not universal thresholds. The right trigger depends on queue growth, resource limits and the time needed to add capacity.
Backpressure and load shedding should protect the most important actions. Noncritical analytics or background refresh can be deferred while the system preserves checkout, authentication or core account functions. A controlled waiting state is often better than accepting work the platform cannot finish reliably.
Figure 02 · Qualitative comparison
Three placement choices, different responsibilities
| Approach or concept | What it contributes | What still matters |
|---|---|---|
| Public cloud | Provides elastic managed infrastructure | Architecture and consumption controls shape the bill |
| Owned datacenter | Retains direct facility and platform responsibility | Capital, staffing and capacity planning remain internal |
| Colocation | Rents resilient space, power and connectivity | The institution still owns critical operating duties |
Correctness requires more than availability
A platform can be available while duplicating a charge, losing an update or returning stale authority information. Resilience must therefore include correctness of the business action. Availability alone is an incomplete measure.
The commerce source described idempotency keys and called the resulting behaviour an “exactly-once” guarantee. That wording is too broad if applied to an arbitrary distributed transaction. Idempotency can prevent duplicate execution within a defined scope when keys, storage and processing rules are correct. It does not automatically create universal exactly-once delivery across independent systems.
Use stable operation identifiers, durable state and reconciliation. Record whether an action was requested, accepted, executed and settled. If a timeout occurs after execution, the system should recover the known outcome rather than initiate a second action. The control boundary and retention period for deduplication should be explicit.
Choose storage according to the data’s role
The media case described several storage patterns:
Historical storage patterns and their data roles
| Aspect | Retained observation |
|---|---|
| Relational data | relational data for structured transactions, |
| Distributed event stores | distributed event stores for high-volume activity, |
| Caches | caches for frequently read or precomputed values |
| Analytical stores | and analytical stores for reporting. |
The transferable principle is to match consistency, access pattern and recovery requirements to the data.
A cache can improve latency and absorb load, but it needs a policy for freshness and loss. Some data can be recomputed; other data represents a durable obligation and must not exist only in an ephemeral layer. A cache miss should produce controlled behaviour rather than a sudden surge that overwhelms the backing store.
Distributed databases also involve trade-offs. Multi-region replication does not automatically provide low-latency global transactions or remove application-level consistency requirements. The architecture should state which writes must be atomic, which reads may be stale and how the system behaves during a partition.
Events separate producers from consumers
An event stream records that something happened and allows several consumers to respond independently. This can decouple transaction services from analytics, notifications and downstream processing. It also makes replay and audit possible where retention and schema design support them.
Events need identifiers, timestamps, versions and clear meaning. Consumers should tolerate duplicates and understand ordering guarantees. A later event may arrive before an earlier one; the application must decide whether to wait, reorder or process idempotently.
The event log is not a substitute for a ledger or a database in every situation. It is a record of changes whose relationship to current state must be designed. The platform should be able to reconcile events with the authoritative state of important transactions.
Observability should follow the customer journey
Measure latency, traffic, errors and saturation across services, then connect those signals to business outcomes. A low infrastructure error rate can hide a high rate of failed payments if the application classifies them incorrectly. An expected customer decline should be distinguished from a technical failure.
Distributed tracing can follow a request across dependencies. Logs provide detail, while metrics show patterns and trends. The system needs common identifiers so operators can move between them. Retention and access should reflect the sensitivity of the information being recorded.
Monitor upper-percentile latency and queue growth rather than relying only on averages. Segment by region, endpoint and important customer flow. A healthy aggregate can conceal a serious local problem.
Figure 03 · Conceptual framework
Can the service degrade safely?
How the parts connect
- Emerging platform failurePath AIsolation and fallback work
- Emerging platform failurePath BFailure propagates across dependencies
- Isolation and fallback workReviewObserved resilience
- Failure propagates across dependenciesReviewObserved resilience
Historical scale illustrates the stakes, not causality
The commerce case cited annual gross merchandise value of USD 292.3 billion in 2024, peak shopping-weekend volumes of USD 11.5 billion in 2024 and USD 14.6 billion in 2025, and an availability target of 99.99%. These are reported historical case figures. They show why a small interruption can matter at scale, but they do not prove that any one architectural change caused revenue growth.
At 99.99% availability, the annual allowance is about 52.56 minutes in a 365-day year. The business impact depends on when those minutes occur and which customers are affected. A platform should define the service boundary and measurement method before quoting the percentage.
The source also described tests at up to ten times ordinary peak load with injected errors. Such tests are valuable only when the workload and failure patterns are representative. A synthetic benchmark can miss a bottleneck in an external provider or an unusual customer journey.
Release control is part of resilience
Small controlled releases can reduce the risk of a large change, but frequent deployment is not automatically safe. A release process needs meaningful tests, staged exposure, monitoring and rollback. A canary should be judged against business as well as technical metrics.
Configuration and policy changes deserve the same attention as code. A routing rule, timeout or access change can affect production materially. Version the change, identify the owner and define the condition for reversal.
Failure exercises should be bounded and planned. Test the loss of a dependency, a region, a queue consumer or a database connection. Confirm that operators receive useful alerts and can follow the runbook. The purpose is to discover weaknesses before an uncontrolled incident, not to create disruption for its own sake.
Degraded service should be designed in advance
Not every feature needs the same recovery target. A platform may preserve core transactions while temporarily disabling personalisation, recommendations or nonessential reporting. The design should identify what remains available, what becomes stale and what must stop because correctness cannot be assured.
This requires business ownership. Engineers can implement a fallback, but the organisation must decide whether the fallback is acceptable for the service. A cached product description may be harmless; a stale permission or account balance can be consequential. The degraded mode should make its limitations visible where they affect the customer’s decision.
Test the transition back to normal operation. Queued work, stale caches and delayed events can create a recovery surge. Releasing the entire backlog at once may recreate the outage. Use controlled draining, reconciliation and observation before declaring the incident complete.
The historical platform cases are most useful when read through this operating lens. The objective is not to reproduce every technology they used. It is to define which customer outcomes must survive a failure and prove that the system preserves them. That proof includes the degraded period and the recovery, rather than ending when a health check turns green.
Incident response has an operating model
Recovery evidence should include financial or business reconciliation where the service creates obligations. A healthy process count and normal latency do not prove that all interrupted actions reached a known outcome. Identify outstanding transactions, duplicated requests and delayed events before closing the incident. This gives support and finance a controlled starting point for any remaining customer cases and prevents an infrastructure recovery from concealing an unresolved correctness problem.
Assign a coordinator, technical owners and a communications role. During an incident, the team should know who can make a recovery decision and who records what happened. Multiple well-intentioned changes can complicate diagnosis if they are not coordinated.
After recovery, distinguish the trigger from the conditions that allowed damage to spread. Track corrective actions to completion. A useful review produces a changed system, test or operating procedure; it is not merely a narrative of the event.
The historical cases support a coherent resilience philosophy: bound waiting, isolate resources, preserve transaction identity, observe the whole journey and rehearse recovery. These practices matter more than copying a particular company’s collection of technologies. The objective is a platform that remains understandable and controlled when its components behave badly.
Primary sources checked for this edition
- ESMA — DORA ICT-risk and third-party framework applies from 17 January 2025 to in-scope entities. Source date: current page checked 2026-10-08. https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora
