Feature: Add Atomic Compare-and-Swap (CAS) API Endpoint #10

Open
opened 2025-09-22 18:23:01 +03:00 by MrKalzu · 0 comments
Contributor

Feature: Add Atomic Compare-and-Swap (CAS) API Endpoint

Description

Implement an atomic compare-and-swap (CAS) operation for the KV API to enable optimistic concurrency control. This would allow clients to update a key only if its current value matches an expected value (e.g., based on UUID or timestamp), reducing race conditions in distributed writes.

Motivation

KVS is eventually consistent with sophisticated conflict resolution (oldest-node rule + UUID tie-breaker), but lacks client-side atomicity for high-contention scenarios. CAS would provide a building block for safer updates without full transactions, aligning with the "local-first" philosophy while improving reliability for apps needing conditional writes.

Implementation Notes

Local Atomicity: Use BadgerDB's transactions for single-node CAS (check + set in one Update txn).
Distributed Handling: On success, trigger normal replication via Merkle sync. On failure, return immediately (no cross-node coordination needed for base impl).
Edge Cases: Handle TTL/compression integration; optional expected field for timestamp-only checks.
Config Toggle: Add cas_enabled: true to Config for opt-in.

Related

Ties into revision history (revision_history_enabled).
Test with integration_test.sh by simulating concurrent CAS attempts.

Feature: Add Atomic Compare-and-Swap (CAS) API Endpoint Description Implement an atomic compare-and-swap (CAS) operation for the KV API to enable optimistic concurrency control. This would allow clients to update a key only if its current value matches an expected value (e.g., based on UUID or timestamp), reducing race conditions in distributed writes. Motivation KVS is eventually consistent with sophisticated conflict resolution (oldest-node rule + UUID tie-breaker), but lacks client-side atomicity for high-contention scenarios. CAS would provide a building block for safer updates without full transactions, aligning with the "local-first" philosophy while improving reliability for apps needing conditional writes. Implementation Notes Local Atomicity: Use BadgerDB's transactions for single-node CAS (check + set in one Update txn). Distributed Handling: On success, trigger normal replication via Merkle sync. On failure, return immediately (no cross-node coordination needed for base impl). Edge Cases: Handle TTL/compression integration; optional expected field for timestamp-only checks. Config Toggle: Add cas_enabled: true to Config for opt-in. Related Ties into revision history (revision_history_enabled). Test with integration_test.sh by simulating concurrent CAS attempts.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ryyst/kalzu-value-store#10
No description provided.