A serialization mismatch occurs when one component produces a data representation that another component cannot interpret. In distributed systems, a small schema change can break communication silently or surface only when a message reaches an older consumer. section 12.0
A practical warning sign is a deserialization error after one service changes its contract. Check which service produced the message, which schema the consumer expects, and where the message failed in its journey. section 12.1.1 section 12.0
An enum value breaks fulfillment
The order service adds SHIPPING_METHOD_DRONE, but the fulfillment service still uses the old schema version. A warning appears: “Failed to deserialize message from topic orders.created - Unknown enum value: SHIPPING_METHOD_DRONE.” The investigation connects the failed message to the producer change and the stale consumer. section 12.1.1
Figure 12.1 An overview of the system for our scenario. The checkout service calls the order service via REST, while the order service asynchronously talks to the fulfillment service through a Kafka topic. The fulfillment service stores details in a database.
Follow the message path from checkout through the order service and Kafka to fulfillment and its database; this separates transport flow from the failing representation. section 12.1.1
Use these questions to narrow the failure:
- Which producer emitted the incompatible value? section 12.1.1
- Which consumer still expects the older representation? section 12.1.1
- Can logs, trace IDs, and spans locate the message’s failing service? section 12.0 section 12.1.1
