ARCHIVED from builddistributedsystem.com on 2026-04-28 — URL: https://builddistributedsystem.com/tracks/migrator/tasks/task-25-2-2-backward-compatibility
TASK

Implementation

Backward compatibility means old clients continue to work after an API update. The golden rule: only make additive changes (new optional fields, new endpoints). Renaming, removing, or changing the type of existing fields breaks old clients.

Implement a node that serves both old and new clients from the same endpoint:

// v1 client: gets the fields it knows about (no new fields needed)
{ "type": "get_users", "msg_id": 1 }  // from client_v1
-> { "type": "users_response", "in_reply_to": 1,
    "version": "v1",
    "users": [{"id":1,"email":"user@example.com","name":"John Doe"}] }

// v2 client: gets new fields added in v2
{ "type": "get_users", "msg_id": 2 }  // from client_v2
-> { "type": "users_response", "in_reply_to": 2,
    "version": "v2",
    "users": [{"id":1,"email":"user@example.com",
               "full_name":"John Doe","phone":"+1234567890"}] }

// Deprecated field: return both old and new, flag old as deprecated
{ "type": "create_user", "msg_id": 3,
  "user": {"email":"new@example.com","name":"Jane"} }
-> { "type": "user_created", "in_reply_to": 3,
    "user": {"id":2,"full_name":"Jane"},
    "__deprecated": ["name"] }

Sample Test Cases

Add optional field (backward compatible)Timeout: 5000ms
Input
{
  "src": "client_v1",
  "dest": "api",
  "body": {
    "type": "get_users",
    "msg_id": 1
  }
}
Expected Output
{"type": "users_response", "in_reply_to": 1, "users": [{"id": 1, "email": "user@example.com", "name": "John Doe"}], "version": "v1"}
New client uses new fieldsTimeout: 5000ms
Input
{
  "src": "client_v2",
  "dest": "api",
  "body": {
    "type": "get_users",
    "msg_id": 1
  }
}
Expected Output
{"type": "users_response", "in_reply_to": 1, "users": [{"id": 1, "email": "user@example.com", "full_name": "John Doe", "phone": "+1234567890"}], "version": "v2"}

Hints

Hint 1
Old clients must work without modification when new optional fields are added
Hint 2
New clients receive the new fields; old clients ignore them
Hint 3
Deprecated fields: return the old field alongside the new one, flag it in __deprecated
Hint 4
Contract validation: ensure API response matches the expected contract version
Hint 5
Never remove or rename required fields — add new optional ones instead
OVERVIEW

Theoretical Hub

Concept overview coming soon

Key Concepts

backward compatibilityadditive changesfield deprecationconsumer-driven contracts
main.py
python
Implement Backward-Compatible API Changes - The Migrator | Build Distributed Systems