Reference Data Management
2026
Single governed source-of-truth for translations and cross-system code mappings. Transactional outbox + RabbitMQ Streams for cache-invalidation only; MongoDB + Redis read-through; BFF page-level aggregation; mobile offline bundle.
The problem
Across the Balady estate, dozens of services maintain their own copies of
translations, code mappings (e.g. service-category-id → display-name),
and lookup tables. Every team handles invalidation differently. Mobile
apps need offline access to a frozen subset.
The architecture
A central source-of-truth that serves reference data to .NET MVC, SPA + .NET BFF, mobile clients, Java services, and partner integrations.
The key constraint: RDM never writes to consumer databases. Consumers own their own caches and decide what to retain. RDM only fires cache-invalidation events when its data changes.
Eleven Architectural Decision Records govern the design, including:
- Transactional outbox + RabbitMQ Streams for cache-invalidation only
- MongoDB as the master store (schema-flexible reference data)
- Redis as the read-through cache
- BFF page-level aggregation — the SPA fetches a page’s reference data in one call
- Mobile critical-flow bundle — a frozen subset of high-priority data shipped with the app for must-work-offline screens
Outcome
One canonical authority for translations and codes. Consuming services no
longer fork drift. Pilot service: healthcertificate.