# Normalizer

> Multiple input formats, one canonical output — normalize before downstream processing.

- **Category**: Integration
- **Subcategory**: Message Transformation
- **Canonical URL**: https://designpattern.fyi/patterns/normalizer/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Multi-channel payment processing — payments arrive as Stripe webhooks (JSON), bank SWIFT messages (ISO 20022 XML), and POS terminal data (proprietary binary). Normalizer converts all three to a canonical PaymentReceived event. Payment processing engine handles one format only.





## Trade-offs


### Advantages

- Downstream consumers have zero knowledge of source format diversity

- Centralizes all format conversion logic in one place

- Adding a new source format only requires one new translator

- Canonical format becomes the stable integration contract




### Considerations & Drawbacks

- Canonical data model design is hard — must accommodate all source formats without losing data

- Each new source format requires a new translator to build and maintain

- Canonical model can become over-complicated trying to serve all sources

- Source format changes require translator updates







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