Bulkhead Pattern – Every SOR Should Have a Separate Thread Pool/Executor Service

Resilence4J Patterns - These patterns will focus only on threads.

Bulkhead Pattern – Every SOR Should Have a Separate Thread Pool/Executor Service

In enterprise banking systems, a single application often communicates with multiple Systems of Record (SORs) — such as Customer SOR, Loan SOR, Payment SOR, or Core Banking.

If one SOR becomes slow or unavailable, it should not impact other SOR integrations.

This is where the Bulkhead Pattern becomes critical.

Ex:

APS Service

   ├── Customer SOR

   ├── Loan SOR

   ├── Payment SOR

   └── Notification SOR

All SOR calls share the same thread pool.

❌ What happens if Loan SOR becomes slow?

• Threads get blocked

• Thread pool gets exhausted

• Customer SOR calls start waiting

• Entire APS system becomes unresponsive

• Production incident

This is called resource starvation.

✅ Solution: Separate Thread Pool Per SOR

Each SOR should have:

• Dedicated thread pool

• Dedicated timeout

• Dedicated circuit breaker

• Dedicated monitoring metrics

Architecture becomes:

Customer SOR → ThreadPool-A
Loan SOR     → ThreadPool-B
Payment SOR  → ThreadPool-C
Notification → ThreadPool-D

Now:

• Loan SOR failure affects only ThreadPool-B

• Other SORs continue working normally

• System stability increases dramatically