Chapter 23 — Observe Consistency Boundaries through Real Ports

Chapter objective: After this chapter, a developer can reproduce propagation between instances using two independent RESP clients, real TCP/UDP ports, and repair diagnostics, and explain why convergence cannot revoke success returned during a partition.

Learning objectives

1. Distinguish the RESP command layer, local projection, DSM mutation batch, and replication/repair layer.
2. Observe online delta, late join, and TCP repair over real sockets.
3. Reproduce two successful SET NX calls and duplicate List pop.
4. Separate E4 black-box evidence from production deployment acceptance.

Prerequisites

• The partition window from Chapter 14 and evidence ladder from Chapter 18 are complete.
• Java 25 and Maven are available; redis-cli is optional for the manual demonstration.
• The example implements a Redis-shaped protocol and is not a Redis-compatible product.

Case progress

The fulfillment team needs a black-box experiment readable by business stakeholders. Node A listens for RESP on 6380, node B on 6381; clients see only Redis-style commands and results while UDP live delta and TCP repair propagate deterministic mutation batches.

The experiment boundary

The protocol layer accepts RESP2 bulk-string arrays and limits transaction queue and mutation-batch size. A projection supplies local String, Hash, List, Set, TTL, and counter views. DSM replicates deterministic mutation batches; it does not pretend that a Redis server is shared memory.

Online and repair paths

While both nodes are online, subsequent writes propagate through UDP live delta. A late or missed node exchanges digests over the TCP data plane and selects replay or snapshot from the available window. INFO DSM exposes local dsm_repair_state, last mode, time, peer, and error.

These fields describe one node. They do not form a globally consistent query. digest_match means that one comparison found no difference.

Both partition-time OK responses happened

SET key value NX checks the ingress node's current projection. After isolating A and B, both can see an absent key and return OK. Recovery and repair converge to one deterministic state without revoking either client's earlier response.

LPOP/RPOP also acts on local projection, so both sides can pop one logical element during a partition. The example is unsuitable as an exactly-once queue, global CAS, or inventory-deduction system.

Counterexample and fault injection

• Cut live delta, run SET NX for one key on A and B, and record both results.
• Pop one List element on both sides and observe that both clients can receive it.
• Write String and Hash state on A while B is offline, then start B and observe bootstrap repair.
• Send a mutation batch larger than 32 KiB and confirm whole-batch rejection without partial apply.

Experiment

Run the automated black box:

cd submodule/dsm-examples/dsm-redis-server
./mvnw -q clean verify

Run the optional manual boundary demonstration:

cd submodule/dsm-examples/dsm-redis-server
./scripts/run-consistency-boundary-demo.sh

Use redis-boundary-observations.json to record client result, node-local view, repair outcome, and unsupported conclusion.

Experiment acceptance card

Review

• Real ports strengthen the execution surface without changing collection semantics.
• Online delta and repair are complementary paths.
• Repair restores convergence and cannot revoke returned business success.
• A familiar protocol is an observation entry point, not a Redis product promise.

Next

Chapter 24 expands to two clusters and states what Register, Lease, and CRDT retain and give up across federation.

Evidence links

• Redis-shaped example boundaries
• RealNetworkBlackBoxTest
• DsmRedisNodeIntegrationTest
• Consistency-boundary demonstration script