Bulkhead & Strangler Fig Patterns — Interview Questions

How to use this lesson

Both patterns are about limiting the blast radius:

• Bulkheads limit it at runtime, by isolating resources.
• The Strangler Fig limits it during migration, by changing one slice at a time.

Give concrete implementations at several levels: code, pods, infrastructure.

Q1. What is the Bulkhead pattern for?

Short answer: It partitions resources (thread pools, connection pools, concurrency limits, instances), so a failure or overload in one part can't exhaust the resources that other parts need. The name comes from the watertight compartments in a ship's hull.

Example: in an airline booking system, calls to the non-critical Loyalty Points service use a small, separate pool. When Loyalty hangs, only that pool fills up. Booking keeps its own threads, and keeps selling tickets. Points are awarded later.

Learn it in depth → Bulkhead & Rate Limiting

Q2. What is the Strangler pattern for?

Short answer: It replaces a monolith gradually. New microservices are built alongside it, a routing facade sends more and more functionality to them, and the monolith's corresponding code is retired, until nothing is left (the "strangler fig" vine that eventually replaces its host tree). Example: a retailer moves Cart and then Payment into services, while the rest of the monolith keeps running. That avoids a risky big-bang rewrite.

Learn it in depth → Monolith to Microservices Decomposition

Q3. What is the Bulkhead pattern, and how does it prevent system-wide failures?

Short answer: Most cascading failures are resource exhaustion. One slow dependency holds threads and connections until none are left for anything else, so the healthy features fail too. Bulkheads put a hard cap on how much of a shared resource any one dependency, tenant or feature can take:

• when a compartment is full, only its requests are rejected quickly (and can fall back);
• the rest of the system has guaranteed capacity.

Q4. How do you implement bulkheads in a microservices architecture?

Short answer: Implement them at several levels:

1. In code (per dependency):
   • Resilience4j SemaphoreBulkhead: caps the concurrent calls. Works well with virtual threads.
   • Or ThreadPoolBulkhead: a separate pool plus a bounded queue.
   • Separate HTTP connection pools per downstream client.
   • Separate executors for different workloads.
2. Per workload type: separate consumer groups or listener containers for critical and bulk topics, and separate database pools (OLTP vs reporting, or read replicas).
3. Per deployment: run critical and non-critical endpoints as separate deployments (the same code, different routes), with their own resource requests and limits, node pools, and autoscaling.
4. Per tenant or cell: cell-based architecture. Shard customers into independent cells (full stacks), so one cell's incident affects only its users. Per-tenant quotas and rate limits.
5. At the edge: rate limiting and priority queues, so low-priority traffic can't starve high-priority traffic.

@Bulkhead(name = "loyalty", type = Bulkhead.Type.SEMAPHORE, fallbackMethod = "deferPoints")
public void awardPoints(BookingConfirmed e) { loyaltyClient.award(e.customerId(), e.points()); }

private void deferPoints(BookingConfirmed e, BulkheadFullException ex) { outbox.add(new AwardPointsLater(e)); }

resilience4j:
  bulkhead:
    instances:
      loyalty:
        max-concurrent-calls: 10     # loyalty can never hold more than 10 request threads
        max-wait-duration: 0         # fail fast instead of queueing

Q5. Give an example where the Bulkhead pattern improves reliability.

Short answer: Online banking. The Transactions (payments), Account and Support services each have:

• their own deployments, pools and quotas;
• inside the Transactions service, separate thread pools for the core ledger and for calls to the slow fraud-scoring and statement-PDF services.

During salary day, PDF statement requests surge, and the PDF generator slows down. Without bulkheads, it consumes the shared request threads, and payments start timing out. With bulkheads, the PDF compartment saturates, and returns "try again later", or queues the PDFs, while payments and balance checks stay fast. Critical flows are protected by design.

Q6. How does the Bulkhead pattern relate to resource isolation?

Short answer: A bulkhead is resource isolation, applied deliberately to contain failures. The resources isolated include:

• compute: CPU and memory requests and limits per pod, dedicated node pools;
• concurrency: threads, semaphores, virtual-thread limits;
• connections: separate database and HTTP pools;
• queues and partitions;
• network and quotas: rate limits per client or tenant.

Key points to cover:

• The trade-off is utilisation vs isolation. Dedicated compartments can sit idle while another is full. Size them from measurements, and keep critical compartments over-provisioned.

Q7. What is the Strangler pattern, and how is it used to migrate a monolith?

Short answer:

1. Put a routing facade in front of the monolith: an API gateway, a reverse proxy, or an ingress.
2. Build one capability as a new service.
3. Route that capability's traffic (by path, header, user cohort or percentage) to the new service.
4. Keep everything else on the monolith.
5. Retire the monolith's code for the migrated capability.
6. Repeat.

At all times, the system works, users see one application, and each step is small and reversible.

# Spring Cloud Gateway as the strangler facade
spring:
  cloud:
    gateway:
      routes:
        - id: cart-new
          uri: lb://cart-service
          predicates: [ "Path=/cart/**", "Weight=cart, 20" ]      # 20% canary to the new service
        - id: cart-legacy
          uri: http://legacy-monolith
          predicates: [ "Path=/cart/**", "Weight=cart, 80" ]
        - id: everything-else
          uri: http://legacy-monolith
          predicates: [ "Path=/**" ]

Q8. What are the key benefits of the Strangler pattern for modernisation?

Short answer:

• Lower risk: no big-bang cut-over. Each slice can be canaried and rolled back by switching a route.
• Continuous value delivery: new services go live early, and the business isn't frozen for a multi-year rewrite.
• Learning as you go: the team builds platform, observability and operations skills on low-risk slices first.
• Prioritisation: migrate the parts with the highest change rate, scaling pain or business value first. Parts that are stable can stay in the monolith, possibly forever.
• The migration can stop anytime in a coherent state.

Q9. How would you implement the Strangler pattern incrementally in a legacy system?

Short answer:

1. Prepare:
   • Put the facade in front, with no behaviour change.
   • Add observability (traffic per endpoint, errors), and characterisation tests.
   • Map the domain and dependencies to pick seams.
2. Choose the first slice: loosely coupled, valuable and low-risk (for example notifications or catalogue search). Avoid the core transactional heart first.
3. Build the service: its own data store, API and pipeline. Use an anti-corruption layer to translate the legacy model.
4. Handle the data:
   • Seed the service's data from the monolith.
   • Keep it synced (CDC or events) during the transition.
   • Decide who's the system of record, and when that flips.
5. Shift traffic gradually:
   • Run a shadow or dark launch (compare the new and old results).
   • Then a canary percentage, then 100%.
   • Monitor and compare the KPIs.
6. Cut over and clean up: remove the monolith's code path, and its tables or access. Update the routing.
7. Repeat, using what you learned. Also intercept new features: build them as services from the start, rather than adding to the monolith.

Q10. What challenges arise when applying the Strangler pattern to a monolith?

Short answer:

• Data entanglement: shared tables, cross-module joins, and transactions spanning the migrated and non-migrated parts. Splitting the data is usually the hardest part. It needs CDC or sync, and a clear ownership flip.
• Dual running: two implementations must behave identically during the transition. There's a risk of divergence, and a need for comparison testing.
• Hidden coupling: the monolith's internal calls, shared sessions and caches, batch jobs and reports that silently depend on the migrated tables.
• The routing facade's complexity, and the performance cost of extra hops. The facade must be highly available.
• Distributed-system costs appear: network latency, partial failures, eventual consistency.
• A long transition: "temporary" integration code lingers, and there's the risk of never finishing, maintaining both forever. Set milestones, and actually delete the legacy code.
• Organisational effort: new skills, parallel roadmaps, and stakeholder patience.

Follow-up questions this topic invites — and their answers

Q: Semaphore bulkhead or thread-pool bulkhead? A: A semaphore limits concurrency on the caller's thread: low overhead, and ideal with virtual threads or reactive code. A thread-pool bulkhead runs calls on a dedicated pool: it isolates the caller's threads too, and enables timeouts on blocking calls, at the cost of context switching and queues.

Q: What is a cell-based architecture? A: The system is replicated into independent cells (each a full stack with its own data), and a thin routing layer maps users or tenants to cells. A failure, bad deployment or noisy neighbour affects one cell only. It's a bulkhead at the architecture level, used by large SaaS providers.

Q: What is the Branch by Abstraction pattern, and how does it relate to the Strangler Fig? A: It's the in-code counterpart. Introduce an abstraction around the component being replaced, move the callers onto it, build the new implementation behind it, switch over (with a feature flag), and delete the old one. It's used when the capability to extract is deep inside the monolith, rather than at the HTTP edge.

Q: How do you verify that a new service behaves like the legacy code? A: Shadow traffic: send copies of real requests to both, and diff the responses. Also characterisation tests captured from the legacy behaviour, canary metrics comparison, and data reconciliation reports during dual-running.