# Format Indicator

> Tell the receiver how to parse the message — format type baked into the header.

- **Category**: Integration
- **Subcategory**: Message Construction
- **Canonical URL**: https://designpattern.fyi/patterns/format_indicator/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Kafka topic receives messages from 3 producers — one sends JSON v1, one JSON v2, one Avro. Each message has contentType and schemaVersion headers. Consumers check headers and route to the right deserializer. No format guessing, no deserialization explosions.





## Trade-offs


### Advantages

- Enables format flexibility and schema evolution on a single channel

- Consumers are self-routing — they pick the right deserializer

- Supports mixed-format channels during migrations

- Pairs well with schema registries (Confluent Schema Registry)




### Considerations & Drawbacks

- Every message carries extra metadata

- Consumers must implement format negotiation logic

- No standard field name across all brokers — teams must agree on conventions

- Stale consumers may not handle new format indicators gracefully







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/FormatIndicator.html)