Catalog
concept#Software Engineering#Architecture#Data#Reliability

Immutability

Principle where data or objects cannot be changed after creation. Promotes predictability, concurrency safety, and testability.

Immutability denotes data or objects whose state cannot be changed after creation.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Databases with versioning or append-only optionsEvent streaming platforms (e.g., Kafka)CI/CD tooling to produce immutable artifacts

Principles & goals

No post-creation state changesExplicit versioning of entities and artifactsCopy-on-write instead of in-place modification
Build
Team, Domain

Use cases & scenarios

Compromises

  • Performance issues due to frequent copies
  • False trust in immutability when interacting with external systems
  • Lack of compatibility with existing APIs
  • Use immutable data types for value objects
  • Combine immutability with copy-on-write and structural sharing
  • Continuously measure memory and latency impact

I/O & resources

  • Existing system state and data models
  • Requirements for consistency, audit and compliance
  • Tooling for versioning and persistence
  • Immutable objects and event logs
  • Improved test cases and reproduction mechanisms
  • Clarified API contracts for state and versions

Description

Immutability denotes data or objects whose state cannot be changed after creation. The concept reduces side effects, simplifies reasoning, aids concurrency and enables more deterministic systems. It is applied in functional paradigms, distributed systems, versioning strategies and improves testability and fault diagnosis.

✔

  • Reduced side effects
  • Easier concurrency and thread-safety
  • Improved reproducibility and testability

✖

  • Increased memory and copy overhead
  • Not all libraries/languages support immutability natively
  • Complexity with large, mutable objects

  • Count of unexpected side effects

    Measure of side-effect related defects before and after adopting immutability.

  • Average memory per request

    Compare memory footprint with and without immutable data handling.

  • Reproducible failure rate

    Share of failures that are deterministically reproducible after concept adoption.

Immutable value objects in Java

Use final fields, no setters, defensive copies for collections.

Event sourcing with immutable events

Events are persisted append-only; state is reconstructed from events.

Immutable infrastructure images

Bake process produces versioned images that are not modified in runtime.

1

Inventory mutable locations and prioritize by risk.

2

Design immutable data types and migration tests.

3

Gradual rollout, monitoring and performance optimization.

⚠️ Technical debt & bottlenecks

  • Legacy APIs requiring mutable contracts
  • Missing infrastructure for efficient storage of historical versions
  • Insufficient tests for migration paths to immutability
Memory consumptionLatency for large copiesInterop with mutable APIs
  • Versioning all data unnecessarily causing storage explosion
  • Forcing immutability while performance-critical hot paths are affected
  • Immutable objects without proper equality/hash implementations
  • Assuming 'const' in a language implies true immutability
  • Missing defensive copies for external inputs
  • Underestimating memory and performance costs
Knowledge of functional programming principlesUnderstanding of persistence and versioning patternsExperience with concurrency models
Concurrency and thread-safetyAuditability and traceabilityDeterministic behavior and testability
  • • Limited native support in some runtimes
  • • Existing systems with mutable contracts
  • • Costs for additional storage and persistence