Primary and Secondary Data Centres

A crypto exchange holds customer funds and runs continuously, so the question of what happens when a data centre fails is not a technical footnote but a business decision. A primary and secondary data centre arrangement means the platform runs in one location and can continue, or recover, from a second one when the first becomes unavailable. It is the difference between a business that stops when a single site goes dark and one that is designed to keep serving customers through the failure.

The decision reads differently to different readers. For a chief executive it concerns continuity of revenue, reputation and the trust of customers who expect access to their funds at all times. For a technology leader it is about topology, failover behaviour and the recovery objectives the platform commits to. For a compliance or operations function it concerns operational resilience, where data resides and how continuity is evidenced to a regulator. This article explains primary and secondary data centres at a conceptual and architectural level. It is not an infrastructure setup guide.

What Primary and Secondary Data Centres Are

A primary data centre is where an exchange normally runs: the location that serves customer traffic, matches orders and records transactions day to day. A secondary data centre is a separate location prepared to take over when the primary cannot serve, whether because of a hardware failure, a network outage, a facility incident or a wider regional disruption. The purpose of the pairing is straightforward: to remove any single location as a point at which the whole business can stop.

The defining trait is deliberate separation. Two environments in the same rack, or even the same building, share too many risks to count as genuine redundancy; a fire, a power event or a connectivity loss can take both at once. Primary and secondary sites are therefore placed so that a single incident is unlikely to reach both, and the platform is designed so that operation can move from one to the other in a controlled way. How that separation is engineered sits below a decision-maker's overview, but the principle is what matters: two sites that fail independently, not two copies that fail together.

Why Redundancy Matters for an Exchange

Exchanges are unusually exposed to downtime. Markets move regardless of whether a platform is available, customers expect to reach their balances at any hour, and an outage during volatility can cause real financial harm as well as reputational damage. Unlike a service that can queue work and catch up later, an exchange that cannot match orders or process withdrawals is failing at its core function precisely when it is needed most.

Redundancy across two data centres addresses this by ensuring that the loss of one location does not become the loss of the service. It also changes how planned work is handled, because maintenance can be carried out on one site while the other serves, reducing the need for disruptive downtime windows. The benefit is not merely uptime as a number; it is the ability to keep custody, trading and settlement functions available through the kinds of events that would otherwise halt them.

Active-Passive and Active-Active

There is more than one way to run two sites, and the choice shapes both resilience and cost. In an active-passive arrangement the primary site serves all traffic while the secondary stands ready, kept current and available to take over when needed. It is simpler to reason about and generally less costly to run, and its resilience depends on how quickly and reliably the switch to the secondary happens. In an active-active arrangement both sites serve traffic at the same time, so a failure removes capacity rather than availability, at the price of greater architectural and operational complexity.

Neither model is universally correct. Active-passive suits operators who want strong recovery without the complexity of running everything in two places at once; active-active suits those for whom even a brief interruption is unacceptable and who have the engineering maturity to operate it. What matters is choosing deliberately, understanding the trade-off between simplicity and continuity, rather than assuming that a second site delivers instant, smooth failover by default.

Recovery Objectives: RTO and RPO

Two figures turn a vague promise of resilience into a commitment that can be designed for and tested. The recovery time objective, or RTO, is how long the business accepts being unavailable before service is restored at the secondary site. The recovery point objective, or RPO, is how much recent data the business can accept losing, measured as the time between the last safe copy and the moment of failure. For an exchange handling funds and orders, both objectives tend to be demanding, because customers and regulators expect fast recovery and no lost transactions.

These objectives are decisions, not defaults. Tighter targets require closer synchronisation between sites and more rigorous testing, and they carry higher cost; looser targets are cheaper but accept more disruption and potential data loss. The important discipline is to set RTO and RPO deliberately, in line with what the business and its regulators actually require, and then to prove them through regular failover testing rather than assuming the secondary site will perform when it is finally called upon.

Geography, Separation and Data Residency

Where the secondary site sits is a decision with two dimensions. The first is distance: sites must be far enough apart that a regional event, such as a power grid or connectivity failure, is unlikely to affect both, yet the separation interacts with how closely the two can be kept synchronised. The second is jurisdiction, because a crypto exchange answering to regulators and customers about where information is held cannot place a secondary site wherever is most convenient without considering data residency.

A two-site design lets an operator keep both primary and secondary within a chosen jurisdiction, such as a United Kingdom region or a specific European Union member state, so that resilience does not come at the expense of residency commitments. It is worth being precise here: hosting data in a given location does not by itself make a platform compliant, and geographic redundancy does not by itself satisfy data-protection obligations. Separation and residency are inputs to sound governance, and a dedicated deployment gives an operator the control to make both choices deliberately rather than inheriting them from a shared platform.

Operating a Two-Site Estate

Running two data centres is more than owning a second location; it is an operating commitment. Keeping the secondary current, monitoring both sites, rehearsing failover, verifying backups and maintaining the runbooks that govern a switchover are ongoing responsibilities, carried either by an internal team or through a managed arrangement with a provider. A second site that is provisioned and then neglected drifts out of step with the primary and offers false comfort rather than real protection.

This is where a familiar principle applies: do not buy software alone; buy the process that makes it work. Redundant infrastructure delivers continuity only when a competent operation stands behind it, exercising the failover path often enough to trust it. The detailed engineering of that operation sits outside a decision-maker's overview, but the requirement does not: a second data centre and a credible way to run and test it are two halves of the same decision, not separable purchases.

UK and EU Expectations

Data-centre design intersects directly with regulatory expectations in Grumpio's core markets. In the United Kingdom, operational resilience, safeguarding and accurate record-keeping are all expectations for firms handling cryptoassets, and registration under the Money Laundering Regulations is a financial-crime gateway rather than full authorisation. The incoming FSMA cryptoasset regime raises the bar further, and an operator that can evidence tested recovery across primary and secondary sites is better placed against resilience expectations than one relying on a single location it cannot fully account for.

In the European Union the framework is settled. The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning, and DORA sets expectations for digital operational resilience, including business continuity, recovery and the management of ICT and third-party risk. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations. A primary and secondary design can support continuity and resilience obligations, but it does not on its own satisfy them; the testing, records and governance around it are what turn architecture into evidence.

Designing the Right Topology

The right topology follows from the operator's tolerance for downtime, its regulatory context and its appetite for operational complexity. An operator pursuing authorisation with demanding continuity needs may justify an active-active design across two jurisdiction-appropriate sites; a smaller operator may be well served by a tested active-passive arrangement; and a minimal early pilot may reasonably begin with a single site and a clear plan to add redundancy as it grows. The mistake is to leave the question unasked until an outage forces it.

The questions to put to any provider follow from this. Are the sites genuinely separated so they fail independently? What are the RTO and RPO, and how are they tested and evidenced? Is the arrangement active-passive or active-active, and what does a real failover involve? Where do the sites sit, and does that respect residency obligations? For a broader view of how deployment and resilience fit the wider platform, the crypto exchange software and technology overviews provide the surrounding context.

Summary and Next Steps

Primary and secondary data centres remove any single location as a point at which a crypto exchange can stop, through deliberate separation, a chosen active-passive or active-active model, and recovery objectives that are set and tested rather than assumed. Geography and data residency shape where the sites sit, and the design delivers its promise only when a credible operation keeps the secondary ready and proves the failover path. Chosen deliberately, a two-site estate is a foundation for continuity and resilience rather than a cost to be minimised. Region-specific expectations are set out on the United Kingdom and European Union readiness pages.