# Message History

> Every component stamps itself on the message — full processing trail baked into the payload.

- **Category**: Integration
- **Subcategory**: System Management
- **Canonical URL**: https://designpattern.fyi/patterns/message_history/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Integration pipeline audit — an InvoiceMessage passes through 6 steps (validation, enrichment, translation, routing, transformation, delivery). Each step appends its ID and timestamp to the message history array. Support team can read the message history to reconstruct exactly what happened to any specific invoice, when, and in what order.





## Trade-offs


### Advantages

- Self-contained tracing — no external tracing infrastructure required

- History travels with the message — always available at any point in the pipeline

- Simple to implement — just an append to an array field

- Enables post-mortem analysis by examining message history




### Considerations & Drawbacks

- Message size grows with each processing step — long pipelines create large messages

- History in the message can be tampered with — not suitable as a security audit trail

- Does not capture failed steps (message did not make it there to stamp history)

- Replaced in modern systems by distributed tracing (OpenTelemetry, Jaeger) which does not pollute message payloads







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