Feature flags vs bulkheads: what to look for in isolation tooling

• Bulkheads and feature flags solve different problems: one partitions resources such as thread pools and connection pools, and the other controls behavior at runtime.
• Judge isolation tooling on scope of containment, speed of propagation, and governance.
• A feature flag change is not instant at the client. The SDK mode sets the landing time: polling SDKs pick up changes on their next refresh interval, and streaming through Unleash Enterprise Edge shortens the delay to milliseconds.
• Infrastructure-layer containment failures fall outside the failures feature flags are designed to stop.
• Pair the two: bulkheads cap the resources a failure can consume, and feature flags cap the users and contexts a change can reach and let you turn it off.

When something fails in production, two questions decide the size of the damage: the first concerns what limits the spread, and the second concerns who can change behavior, and how fast. People use “isolation” for both answers, but it covers two different mechanisms, since bulkheads partition resources while feature flags control behavior at runtime.

This article compares feature flags vs bulkheads isolation tooling for platform, product, and engineering leaders who are making a buying or architecture decision. It gives you 3 core criteria for judging any tool (containment scope, propagation speed, and change governance) plus 2 follow-up checks on automation and operability, covering bulkheads, feature flags, a side-by-side comparison, evaluation criteria, the limit of feature flags, and combining the two.

Bulkhead isolation for resource limits

Here is what a bulkhead protects and where it stops. A bulkhead divides a system into compartments so one failure does not exhaust shared resources. The bulkhead pattern is commonly implemented with separate thread pools, processes, containers, or resource pools, and if one compartment fills with stuck requests, the others keep their own threads, connections, and memory.

A bulkhead isolates a resource such as a pool, an instance, or a set of database connections, and it addresses exhaustion, where one slow dependency or one runaway workload consumes capacity that everything else needs. A bulkhead can live in an application library, an orchestrator limit, or an infrastructure partition.

A resource-pool bulkhead does not control user access to a code path: when a compartment is full it queues or rejects calls, and changing its limits is a configuration change. If a new release ships a bad code path, a bulkhead limits the resources that path can consume, yet it does not remove the path from the users who reach it.

Feature flag isolation

Here is how feature flags limit who sees a change. A feature flag controls the active behavior per context at runtime. An activation strategy determines the audience for a feature: a flag is enabled if at least one of its strategies resolves to true, and all constraints within a single strategy must be true for that strategy to resolve to true. Feature flags isolate behavior and address a change that misbehaves, such as a new feature, a new code path, or a new integration.

Three controls limit the number of users a change can reach, which sets its blast radius. First, rollout percentage exposes a feature to a stable fraction of users. Second, targeting restricts it to defined contexts. Third, segments package reusable constraints.

Environments work differently because they keep configuration separate per stage. Development and production exist by default, and creating more environments is an Enterprise capability. The three exposure controls are the working parts of progressive delivery, which exposes a change gradually on a plan, and a canary release is one familiar example of that exposure pattern.

A feature flag can also turn off a single feature without a redeploy, and feature flags are a primary mechanism behind a kill switch, though not the only one. The trade-off is added code complexity, because each flagged path is a branch you maintain and eventually remove.

Why flag changes are not instant

A feature flag change is not instant at the client, because the SDK mode sets the landing time. Polling is the default: backend SDKs refresh every 15 seconds by default and most frontend SDKs every 30 seconds, so a change reaches SDKs on their next refresh. Streaming through Unleash Enterprise Edge shortens the delay, and streaming-mode SDKs fall back to polling if the stream fails, while Edge reconnects and keeps serving cached data meanwhile.

With Enterprise Edge in the path, count each hop: Edge polls upstream (15 seconds by default) and SDKs poll Edge, and Edge streaming does not make SDKs real time unless the SDK also runs in streaming mode. When you evaluate speed, ask for the propagation mode, the interval, and the fallback behavior.

Also ask for the SDK’s behavior when the flag service is unreachable: the SDK keeps serving cached or bootstrapped state, and falls back to false or a configured fallback when no data exists. A kill switch is only as useful as your understanding of its behavior when the flag service is part of the outage. Next, how the two mechanisms work side by side.

Feature flags vs bulkheads as isolation tooling, side by side

Compare the two across five dimensions.

• Unit of isolation: A bulkhead isolates a resource compartment, whereas a feature flag isolates a behavior for a context.
• Failure type addressed: A bulkhead addresses resource exhaustion that spreads, and a feature flag addresses a change that misbehaves.
• How a change is made: For a bulkhead, it depends on the implementation, such as library configuration, orchestrator limits, or infrastructure. For a feature flag, you make a runtime change that SDKs pick up through polling or streaming.
• Who owns it: Bulkhead ownership commonly varies across service, platform, and infrastructure teams, while feature flags typically belong to feature owners, with platform oversight.
• Signals you watch: For bulkheads, watch saturation, queue depth, and latency to size and monitor compartments; for feature flags, watch error rates, user impact, and metrics to time exposure changes.

These are different layers, and infrastructure controls and feature-level controls answer different questions. A rolling deployment is an infrastructure technique, and a feature flag is an operational control on top of it. Bulkheads are a different case because they are a resource-partitioning control that can live in application libraries, orchestrator limits, or infrastructure partitions.

Criteria for isolation tooling

Containment scope and propagation speed

Start with the tool’s containment scope: a bulkhead contains resource exhaustion while a feature flag contains a bad code path or an exposure decision. Ask a vendor which containment type each feature addresses. A flag can switch off a resource-heavy feature to reduce load, but it does not cap what a workload consumes. If you need resource and behavior containment, configure bulkheads in your libraries, orchestrator, or infrastructure, and add feature flags for runtime behavior control.

When you compare bulkhead mechanisms, ask about per-dependency limits, whether a full compartment rejects or queues calls, which saturation metrics it exposes, and whether limits apply per instance or per fleet.

Then ask for the path a change takes to running instances. For feature flags, the answer is the SDK mode (polling interval or streaming) and its fallback behavior, and your tooling should state it plainly, whereas for bulkheads the answer depends on the implementation: library configuration, orchestrator limits, or an infrastructure change. Either way, measure the time from decision to effect and compare it to the time your incident process allows.

Governance and auditability

Ask for the permission model per environment, and look for per-environment configuration. Environments let you keep production changes separate from development ones, and environment-scoped API tokens add a second layer of control.

In Unleash, projects group feature flags by team or module and attach project roles. Segments reuse constraints so you define a targeting rule once rather than copy it. In practice, environment separation keeps a development change from reaching production; project roles, together with the project’s collaboration mode, limit who can change flags directly or submit change requests; and segments stop a targeting rule from drifting apart across copies.

Also ask about audit trail and approvals: change requests and an event log bear on the change history and the approver. Confirm each feature’s recorded fields and the plan that includes it.

Finally, check plan availability for everything above, because creating more environments, creating or updating projects, and Actions are Enterprise capabilities. Note: streaming through Unleash Enterprise Edge needs the Enterprise Edge add-on.

Safeguards and Signals automation

Some safeguards react to metrics rather than waiting for a person. Production signals tied to feature flags can use impact metrics to pause a rollout or turn a flag off when a threshold is crossed, and the safeguard actions include Disable environment and Pause release plan automation.

Check reaction time before you rely on automation, and keep the two mechanisms apart. For internal metrics, metric-driven safeguards depend on SDK metric batching (60 seconds by default, with a resulting 1 to 2 minute ingestion delay) and the threshold window you configure, whereas external Prometheus or VictoriaMetrics metrics skip that batching. When a safeguard disables an environment, SDKs still pick it up on their next refresh.

Signal-driven actions have their own processing limits: signals are processed once every minute, with a maximum of 10 signals per cycle and a maximum of 5 action sets per project, and self-hosted installs can override those values. A reaction time measured in minutes suits some failure modes and not others, so match it to your own tolerance.

Operability at scale

Keep in mind the default segment limits: 1,000 constraint values per segment, 5 segments per strategy, and 300 segments per instance.

Then check your visibility into propagation, because Enterprise Edge observability reports per-node region, status, version, CPU and memory, stream clients, and upstream and downstream latency. Without that visibility, judging propagation speed in practice is harder, though you can still measure it yourself.

The limit of feature flags

Here is where feature flags stop. The boundary of this comparison is infrastructure-layer containment, and an OpenAI sandbox escape marks that line. The industry described it as a containment failure at the infrastructure layer and, as we wrote at the time, not something a simple feature flag would have stopped.

That escape was a security-boundary failure rather than resource exhaustion, so resource bulkheads do not address it either. If your risk is a workload escaping its boundary or exhausting shared capacity, buy infrastructure isolation.

That post also cites two 2025 incidents as cases of changes that spread without flag protection: a global Google Cloud outage after a routine change, and hours of Cloudflare disruption after a change that doubled the size of a configuration file. Both providers’ own postmortems back this up: Google noted that flag protection would have caught the issue in staging, and Cloudflare committed to enabling more global kill switches. Even so, they illustrate a failure feature flags are designed to contain, a change that spreads further than you intended.

Combining bulkheads and feature flags

Here is how the two fit together. Graceful degradation draws on bulkheads, circuit breakers, timeouts, retries with backoff, and load shedding. Feature flags are the layer that switches fallback paths and risky features on and off at runtime, whereas bulkhead sizing, timeouts, and retry settings live in configuration or infrastructure.

Bulkheads limit the resources a failure can consume, and feature flags limit a change’s reach and let you turn it off. Kill switches are reactive rather than proactive, so they help only after a problem has reached users. That is why you pair them with bulkheads and with gradual exposure rather than rely on either alone.

With Unleash, you get the runtime control layer in that pairing: feature flags, environments, projects, and metrics-driven actions.

Take your next step

If you’re weighing runtime control alongside the bulkheads you already run, we’re happy to walk through environments, projects, and automated actions in your setup. Book a demo to experience it firsthand.

FAQs

Are feature flags a replacement for bulkheads?

No. Bulkheads keep one failure from exhausting shared capacity, and feature flags choose the active behavior per context. Infrastructure controls and feature-level controls answer different questions, so teams that face both failure types need both.

What does a bulkhead protect that a feature flag cannot?

A bulkhead protects shared resources such as threads, connections, and memory from one runaway workload. A feature flag does not partition resources or stop a workload from consuming them, though it can switch off a resource-intensive feature to reduce load. A feature flag also cannot stop a security-boundary failure such as the OpenAI sandbox escape, which we described as a containment failure at the infrastructure layer, and resource bulkheads do not address that either.

Can a feature flag act as a kill switch?

Yes, for a single feature. A feature flag turns off a feature without a redeploy, which makes it a primary mechanism behind a kill switch. The trade-off is code complexity, because each flagged path is a branch you maintain and eventually remove.

How fast does a feature flag change reach running services?

Not instantly, because it depends on the SDK mode. Polling is the default in Unleash, with a 15 second interval for backend SDKs (30 seconds for most frontend SDKs), and streaming through Unleash Enterprise Edge shortens the delay. Ask any vendor for the propagation mode, the interval, and the fallback behavior, then compare that time to what your incident process allows.

Can metrics trigger isolation automatically?

Yes, within limits. Production signals tied to feature flags can use impact metrics to pause a rollout or turn a flag off when a threshold is crossed, and the documented safeguard actions include Disable environment and Pause release plan automation. Reaction time depends on metric ingestion, your configured threshold window, and the SDK refresh interval. Separately, signal-driven actions process signals once every minute, with a maximum of 10 signals per cycle and 5 action sets per project, so match those reaction times to your tolerance.

How do you govern who can change a feature flag in production?

Look for per-environment configuration with environment-scoped API tokens, projects that group feature flags by team or module with project roles, and segments that define a targeting rule once. Also ask about audit trail and approvals, and check which plan includes each capability.