Back to Catalog
Integration
Message Transformation
Normalizer
Multiple input formats, one canonical output — normalize before downstream processing.
Intent & Description
Real-world Use Case
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.
Source
📌 TL;DR
Normalizer = many input formats, one output format. Build one translator per source, emit canonical events downstream. Downstream consumers stay blissfully format-agnostic.
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
Disadvantages
- 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