Designing for Partitions

Swytch continues serving local reads and ordinary writes when nodes lose contact with each other. Transactions have a configurable safety policy: by default, Swytch checks that the relevant peers are available before attempting a transaction. Swytch 1.6+ lets you change that policy for the whole database or for individual keys and key patterns.

The choice is about transaction availability during a partition, not whether Swytch retains the causal history of accepted operations. Both policies use the same transaction coordination, DAG reconstruction, and deterministic conflict arbitration.

Safe mode is the default. Before a transaction proceeds, Swytch checks the availability of peers subscribed to the affected keys. If a required peer is unreachable, the transaction cannot proceed normally. Ordinary, non-transactional commands can continue on the disconnected nodes and their effects reconcile when histories meet.

Unsafe mode skips that availability preflight. Transactions can proceed even when some subscribed peers cannot be reached. This can keep an application working during a partition, but it also allows independently accepted transaction histories to compete when the network reconnects.

Safe mode reduces the chance of that conflict; it is not a guarantee that the network cannot change after preflight. Both modes use the same ACK/NACK coordination and deterministic arbitration.

Configure the default with Redis CONFIG:

CONFIG SET cluster_safe_mode safe
CONFIG SET cluster_safe_mode unsafe

Override individual keys or patterns without changing the database default:

CONFIG SET cluster_safe_mode safe
CONFIG SET key_safe_mode '{"sessions::*":"unsafe","inventory:unique:*":"safe"}'

CONFIG SET key_safe_mode replaces the entire override map. Changes propagate through normal Swytch subscriptions, so different nodes may temporarily apply different policies until they receive the updated configuration. See safety policies for matching rules, precedence, and backing keys.

Swytch does more than broadcast a transaction and wait for a timeout.

1. Preflight (safe mode). Check whether relevant subscribed peers are available before attempting the transaction. Unsafe mode omits this check.
2. Announce and coordinate. The transaction is announced in the causal DAG. Participating peers examine the relevant histories and return ACK/NACK responses. Their responses also constrain the initiation of competing transactions.
3. Resolve visibility. Swytch uses its existing transaction and horizon rules to avoid exposing incomplete competing histories. Reconstruction and deterministic fork choice determine the visible result when histories meet.

The transaction protocol coordinates among the participants that can be identified and reached. It does not create a global coordinator or make disconnected consistency scopes agree instantly.

A partition or connection failure can interrupt coordination after a transaction has been announced. Some peers may already have recorded the transaction while the initiating node can no longer establish whether it committed.

An unsuccessful EXEC result is not necessarily proof of an abort. If the transaction was announced, its record remains in the causal DAG. It may ultimately be committed, or it may not. The response tells the client that the outcome could not be confirmed—not that the announcement can be erased.

This is normal distributed-commit uncertainty, not a Swytch-specific inconsistency. In Raft-based systems, for example, a client can time out after its operation has entered the replicated log without knowing whether it committed. The client must treat that outcome as unknown. An operation rejected before announcement is different: it has not entered the transaction history.

Swytch preserves announced history rather than discarding it because a client didn’t receive confirmation. Once connectivity returns, nodes can discover the histories, apply the existing horizon and deterministic arbitration rules, and reconstruct the resulting state. When unresolved competing transactions are detected, Swytch 1.6+ also exposes their recorded inputs, outputs, and effects as conflict reports, allowing applications to inspect and reconcile them. Reporting requires the histories to be discovered and meet the reporting conditions; not every unsuccessful EXEC produces a conflict report.

If an EXEC outcome is uncertain, do not blindly repeat irreversible work on the assumption that nothing happened. Use application-level identifiers and idempotency where retries can have external effects. A database commit cannot undo a payment, email, or other action outside Swytch.

Swytch 1.6+ exposes transaction conflicts through normal Redis keys. When reconstruction discovers competing transactions that meet the reporting conditions, the engine writes evidence and appends notifications.

For example:

LRANGE __swytch::conflict::__swytch 0 99
BLPOP __swytch::conflict::inventory:unique:42 0
JSON.GET __swytch::conflicts::<txid> .

A network reconnection does not automatically emit a report everywhere. A node must discover and inspect the relevant histories. Reports are historical evidence; their presence does not mean a conflict remains unresolved. Duplicate notifications are possible and should be handled by consumers.

The reporting keys follow Swytch’s normal replication and retention behavior. They are not a permanent audit archive. See transaction conflicts for the document schema, notification behavior, and reconciliation workflow.

You don’t have to choose one policy for every kind of data.

For example, a multiplayer game could keep player progression and ordinary world interactions available during a regional network problem, while requiring safe transactions for trades involving unique items. Only the operations that need stronger coordination have to wait.

Other applications may prefer safe transactions for all keys. The tradeoff depends on what a temporary interruption costs compared with the cost of reconciling competing decisions afterward.

When using unsafe transactions, decide how your application should handle reports before you need them. A new transaction can record a corrected state, but it cannot undo an action that already happened outside Swytch. Payments, messages, and other external effects need their own idempotency or compensation handling.

You can also reduce the likelihood of competition by keeping writes to particular keys within one region, tenant, or device whenever that fits your application. Other nodes can still subscribe to and read the data. This is an application design choice, not a requirement of Swytch’s replication model.

For recoverability beyond locally resident effects, see local durability and Swytch Cloud.