ARCHIVED from builddistributedsystem.com on 2026-04-28 — URL: https://builddistributedsystem.com/tracks/store/tasks/task-7-4-client-dedup
TASK

Implementation

Handle client retries without duplicate execution:

  1. Client assigns sequence number to each request
  2. Server tracks (client_id -> latest_seq, response)
  3. If request seq <= latest_seq, return cached response
  4. Otherwise, process and cache new response

This makes at-least-once delivery safe for non-idempotent operations.

Sample Test Cases

First request executesTimeout: 5000ms
Input
{"src":"c0","dest":"n1","body":{"type":"init","msg_id":1,"node_id":"n1","node_ids":["n1"]}}
{"src":"c1","dest":"n1","body":{"type":"write","msg_id":2,"key":"x","value":1,"client_id":"c1","seq":1}}
Expected Output
{"src":"n1","dest":"c0","body":{"type":"init_ok","in_reply_to":1,"msg_id":0}}
{"src":"n1","dest":"c1","body":{"type":"write_ok","in_reply_to":2,"msg_id":1}}

Hints

Hint 1
Client assigns unique ID to each request
Hint 2
Server tracks latest response per client
Hint 3
Duplicate request returns cached response
OVERVIEW

Theoretical Hub

Exactly-Once Semantics

Network issues cause retries. Without deduplication, a PUT might execute twice. By tracking client sessions and sequence numbers, we can detect and skip duplicates.

Session State

The deduplication table must survive leader changes. Store it in the replicated state machine. Periodically garbage collect old sessions.

Key Concepts

idempotencyclient sessionsdeduplication
main.py
python
Handle Client Retry and Deduplication - The Store | Build Distributed Systems