Why Event-Driven Configuration Is Critical for Banking BCP

Business continuity planning in banks is often discussed in terms of infrastructure– secondary data centres, failover strategies, disaster recovery drills. 

What’s discussed far less is eventing strategy. 

In modern retail banking systems, configuration changes are just as critical as transactions. Limits, policies, and rules must propagate reliably across channels, even during partial outages or infrastructure transitions. When eventing is tightly coupled to a single environment, continuity becomes fragile. 

We encountered this challenge while working on a retail banking platform where configuration updates were being moved out of the core system and distributed to multiple channels. The question wasn’t whether to use events, but how to design them for long-term resilience. 

The answer was abstraction. 

Instead of binding the system to a single event mechanism, the eventing layer was designed as a configurable pipeline. On-premise Kafka was used in some environments. Cloud-native services like GCP Pub/Sub or AWS equivalents were used in others. 

Crucially, switching between them required no change to business logic. 

This distinction matters. Kafka and cloud pub/sub systems solve the same problem in very different deployment contexts. One is often preferred for on-premise setups, the other for cloud-native environments. Regulatory requirements, data residency, or outage scenarios can force a shift between the two. 

By abstracting the event layer, the platform could move seamlessly between cloud and on-prem deployments while preserving consistent behavior across channels. Configuration updates continued to flow. Caches stayed in sync. Transactions were unaffected. 

This wasn’t a cosmetic choice. It was foundational to BCP.

During outages, migrations, or infrastructure constraints, the system could continue operating predictably. Configuration didn’t become a single point of failure simply because the environment changed. 

This level of resilience doesn’t come from redundancy alone. It comes from designing for replaceability. 

The work to build this abstraction was small in surface area, but critical in impact, and was engineered end-to-end by Josh. 

If you’re interested in how event-driven configuration, cloud/on-prem switching, and BCP considerations were handled in a live retail banking platform, the full case study walks through this architecture in detail.