Skip to content

Stateful Workloads and Storage

Stateless applications are naturally easy to distribute across regions. Stateful applications require the location of their data to be treated as part of the architecture — a volume that exists in one region is not automatically available in the others.

Stateless workloads spread across regions, replicated databases, and volumes that do not cross the regional boundary

Compute can be distributed. Data requires an availability strategy compatible with that distribution.

Compute mobility ≠ data location

This is the central distinction in any multi-region architecture:

Stateless workloads Stateful workloads
Where they run Any zone with capacity Where the data is
How they recover A new replica on another node Promotion of a replica with consistent data
What the scheduler needs to know Resources and spread Volume topology
Cost of getting it wrong One restarted pod Data loss or divergence

Kubernetes uses storage topology information to prevent a workload from starting in a region where its volume does not exist. That is protection, not a limitation: a database that comes up without its data is worse than a database that does not come up.

Replication belongs to the data technology

For an application to survive the complete loss of a region, replication has to be handled by the application itself or by the storage technology — each region keeps its own storage, and whatever understands the data controls the replication.

Technologies we operate in this model:

  • replicated relational databases — MySQL and PostgreSQL;
  • distributed databases with local writes in several regions — CockroachDB;
  • queue and streaming platforms — Kafka;
  • search and analytics — Elasticsearch / OpenSearch, ClickHouse;
  • storage platforms with regional replication.

Continuous replication, not emergency transfer

The classic mistake is assuming that, if the region fails, the data will be copied to the other one. Moving large volumes over the WAN after the region has already failed is not a continuity plan. Replication has to be running before the incident.

High availability for stateful workloads

When an application must survive the loss of a region, the minimum arrangement is a primary in one region and a replica in the other, each with its own storage — for example, PostgreSQL in br-sp-1 replicating to br-sp-2, or a primary at InteSys replicating to a public cloud.

Depending on the technology, replication and leader election are handled by the application, the database engine or the storage platform. What does not change are the requirements the architecture has to meet:

  • quorum with an odd number of voters;
  • deterministic leader election;
  • fencing of the old primary before any promotion;
  • split-brain prevention during a network partition;
  • lag monitoring — a replica that silently fell behind is not a replica.

The per-technology detail — replication modes, the RPO of each arrangement, the failover sequence — is in the Database Administration section.

Backup is still mandatory

Cross-region replication covers infrastructure failure. It does not cover DROP TABLE, a buggy deploy, logical corruption or ransomware — those are replicated faithfully to every replica, within seconds.

That is why, even in a multi-region architecture, the cluster carries backup with tested restore and point-in-time recovery, stored off the nodes it protects.

Data sovereignty

A topology across br-sp-1 and br-sp-2 keeps primary data, replicas, logs and backups inside Brazil, under Brazilian jurisdiction and with no international transfer of personal data.

When the architecture includes a region outside the country, that becomes a compliance decision — documented in the solution design, scoped to only what actually needs to leave, and never a platform default.