What problem we’re solving
GIAS receives establishment data from different users and systems. The future may include automated sources, bulk uploads, and human‑reviewed changes. We need an ingestion approach that supports multi‑step workflows, validates data consistently, integrates with other systems, and can scale.
What we built
The prototype is based on three ideas:
- Clean separation between business rules and technical concerns.
- A domain model that reflects the real business meaning of an Establishment.
- Event‑driven communication so downstream systems can react reliably.
The platform uses the Outbox pattern to guarantee that events are never lost, even if downstream systems are temporarily unavailable.
How the workflow works
- A request comes in to create an establishment.
- The domain model validates the request and raises a domain event.
- The event is stored safely in the Outbox.
- The workflow is paused using a cache until approval.
- Approval completes the workflow, raising another event and removing pending state.
Why caching matters
Caching supports multi‑step workflows and keeps performance high. It enables tracking of pending requests, future workflow patterns, and distributed scaling.
Why this architecture matters
The design is reliable, extensible, cloud‑ready, technology‑agnostic, and future‑proof. It supports more complex ingestion needs and integrates well with modern Azure services.
Where this could go next
Future possibilities include automated onboarding, event‑driven data sharing, serverless pipelines, auditing based on Outbox history, and integration with cloud data platforms.
Written by Spencer O’Hegarty, Senior Software Engineer