CONCEPT Cited by 1 source

Configuration bloat¶

Definition¶

Configuration bloat is a multi-tenant SaaS failure mode where a tenant's accumulated configuration entities (custom fields, work types, screens, schemes, workflows, security levels, permissions, components, versions, …) grow unbounded over time, producing:

Slower core read paths — view, search, list operations pay per-entity cost on every render.
Heavier per-tenant data shapes — every additional entity type expands the tenant's configuration footprint in caches, indexes, and API responses.
Higher admin overhead — operators spend more time hunting through obscure screens and schemes to understand the tenant's effective configuration.
Eventual collision with hard limits — once the tenant exceeds a documented cap (e.g. 700 fields per space, 150 work types per space, 20,000 field options per field), further configuration changes are rejected.

(Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

The 2026-05-14 Atlassian post is the first canonical wiki home for this concept. Verbatim framing: "Over time, many of these entities become unused or redundant. The result is configuration sprawl — slower experiences, heavier data shapes, and higher admin overhead."

Mechanism¶

Configuration bloat compounds because three factors all push in the same direction:

Entity creation is local but visible globally. A team adds a custom field for one workflow; the field shows up in every screen and scheme it gets attached to, every API response that includes its parent entity, and every search index. Local additions globalise.
Entity removal is operationally risky. Removing a field that might be used somewhere can break dashboards, filters, automations, or downstream integrations. The default safe action is to leave the entity in place.
Entity reuse is expensive to determine. Without pre-computed usage reports, "is this field still used?" requires scanning all work items + screens + schemes + filters in the tenant. At scale, this is too expensive to compute on-demand from an admin UI.

The combination produces monotonic configuration growth: entities accumulate, are not removed, and are eventually hidden from human attention because the surface area grows faster than admin attention does.

Why this is a multi-tenant problem specifically¶

In a single-tenant deployment, configuration bloat is a self-inflicted "my own users created too much config" problem; the tenant operator can scope and prioritise cleanup without affecting anyone else. In a multi-tenant SaaS:

Limits become a shared-substrate concern. The platform must enforce per-tenant caps to protect concepts/noisy-neighbor isolation; without caps, one tenant's runaway configuration can expand storage or query cost for the substrate that serves all tenants.
The platform must also ship the cleanup tools. Caps alone are insufficient — tenants will hit them, and admins need a way back under without breaking their setups. "These limits protect and improve core experiences ... but they also create a new problem: how do we help customers get under the limits without breaking their setups?" (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)
Pre-computation is required for tractable cleanup. An admin asking "which fields are unused?" across millions of work items cannot wait for a synchronous answer; the platform must run async per-tenant scans and store the result. See patterns/asynchronous-precomputed-report-batch-framework for the canonical platform-level pattern.

Adjacent concepts¶

concepts/catalog-bloat-multi-tenant — the application-schema-layer cousin of configuration bloat. Same root failure-shape (per-entity-type cost × many tenants = unsustainable footprint), different altitude: catalog bloat is about Postgres pg_class entries growing with table count; configuration bloat is about per-application-entity counts growing with admin actions.
Technical debt — configuration bloat is the operator-visible form of accumulated tech debt; tech debt at the application code layer is the engineer-visible form. Same compounding dynamic, both require deliberate paydown discipline.
Schema evolution — fundamentally configuration bloat is a schema-evolution-without-deletion problem at the per-tenant administrative layer. The fix shape is the same as code-level dead-code elimination: identify unused, remove safely, repeat.
concepts/garbage-collection (when present) — the administrative-layer analogue. Just as runtime GC reclaims unreachable objects, configuration optimisation tools reclaim unreferenced configuration entities.

Mitigations¶

Limits and guardrails — hard caps on per-tenant entity counts make the failure mode visible and force cleanup before unbounded growth.
Pre-computed usage reports — per-tenant async scans that determine "which entities are unused" and store the answer for cheap consumption from admin UIs. See Atlassian's Pre-computation Framework for the canonical multi-tenant SaaS instance.
Bulk-remediation actions — opinionated, pre-curated bulk-cleanup operations that consume the report and perform safe configuration mutations. See systems/atlassian-jira-optimisation-tools.
Audit-log-mediated rollback — every cleanup action written to the audit log so admins can reverse if needed. See patterns/audit-log-as-rollback-substrate.
Utilisation-prioritised refresh — prioritise compute budget for tenants near limits, not all tenants uniformly. See concepts/utilization-prioritised-refresh-strategy.

Seen in¶

sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat (2026-05-14, Atlassian) — first canonical wiki home. Names "configuration sprawl" with the canonical three-symptom triad (slower experiences / heavier data shapes / higher admin overhead), Jira's specific limits table (700 fields / 150 work types / 20,000 field options / 50 issue security levels / 50 grants), and the optimisation-tools answer architecture.