Immutability for safety in LLD - System Design Exercise

Design: Immutability for Safety in Software Systems

Focus on designing immutability principles and data flow in a software system to ensure safety and concurrency. Out of scope are specific UI designs or database engine internals.

Functional Requirements

FR1: Ensure data objects cannot be changed after creation to prevent accidental or malicious modification.

FR2: Support concurrent access to shared data without locks or race conditions.

FR3: Allow safe sharing of data across different parts of the system or threads.

FR4: Provide mechanisms to create new versions of data when updates are needed without altering original data.

FR5: Maintain system performance with immutable data structures.

Non-Functional Requirements

NFR1: System should handle up to 10,000 concurrent users accessing shared data.

NFR2: Latency for read operations should be under 100ms p99.

NFR3: Availability target of 99.9% uptime.

NFR4: Memory usage should be optimized to avoid excessive copying of data.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Immutable data structures (e.g., persistent collections)

Versioning or copy-on-write mechanisms

Concurrency control without locks

Garbage collection or memory management for old versions

APIs for creating and accessing immutable data

Design Patterns

Persistent data structures

Copy-on-write

Event sourcing

Functional programming principles

Snapshot isolation

Reference Architecture

Client
  |
  v
Immutable Data API Layer
  |
  v
Immutable Data Store (Persistent Data Structures)
  |
  v
Version Manager & Garbage Collector

Components

Immutable Data API Layer

Custom library or service layer

Provides interfaces to create, read, and update data immutably by returning new versions without modifying originals.

Immutable Data Store

Persistent data structures (e.g., trees, tries)

Stores data in immutable form allowing sharing of unchanged parts between versions to save memory.

Version Manager

Service or module

Tracks different versions of data objects and manages access to correct versions.

Garbage Collector

Background process

Cleans up old versions of data no longer referenced to free memory.

Request Flow

1. Client requests data read via Immutable Data API Layer.

2. API Layer fetches requested version from Immutable Data Store.

3. Client requests data update via API Layer.

4. API Layer creates a new immutable version of data using persistent data structures.

5. New version is stored in Immutable Data Store and registered with Version Manager.

6. Old versions remain unchanged and accessible until no longer needed.

7. Garbage Collector periodically removes unreferenced old versions.

Database Schema

Entities: - DataObject: id (PK), content (immutable), version_number, parent_version_id (nullable) Relationships: - Each DataObject version links to its parent version (if any) forming a version chain. - Multiple versions can coexist; only one is active or latest per logical data entity.

Scaling Discussion

Bottlenecks

Memory usage grows with many versions due to data copying.

Version Manager can become a bottleneck managing many versions.

Garbage collection pauses can affect latency.

Read latency may increase if many versions exist.

Solutions

Use structural sharing in persistent data structures to minimize copying.

Shard Version Manager by data partitions to distribute load.

Implement incremental or concurrent garbage collection to reduce pauses.

Cache frequently accessed versions to reduce read latency.

Interview Tips

Time: Spend 10 minutes understanding immutability benefits and challenges, 15 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 10 minutes for questions and clarifications.

Explain why immutability improves safety and concurrency.

Describe how persistent data structures enable efficient immutable data.

Discuss versioning and garbage collection to manage data lifecycle.

Highlight trade-offs between immutability and performance.

Show awareness of scaling challenges and practical solutions.

Practice

1. What is the main benefit of using immutability in system design?

easy

A. It allows faster data processing by skipping checks.

B. It makes data changeable by multiple users at the same time.

C. It prevents data from being changed after creation, improving safety.

D. It reduces the size of data stored in memory.

Solution

1. Step 1: Understand immutability meaning

   Immutability means data cannot be changed once created.

2. Step 2: Identify safety benefit

   This prevents accidental or concurrent changes, improving safety.

3. Final Answer:

   It prevents data from being changed after creation, improving safety. -> Option C

4. Quick Check:

   Immutability = Prevents changes [OK]

Hint: Immutability means no changes allowed after creation [OK]

Common Mistakes:

• Thinking immutability allows data changes
• Confusing immutability with performance optimization
• Assuming immutability reduces memory size

2. Which of the following code snippets correctly creates an immutable data structure in a low-level design context?

easy

A. Using a constant object or final class with no setters.

B. Using a regular class with public fields that can be changed.

C. Using a mutable list that allows adding or removing items.

D. Using a global variable that can be updated anytime.

Solution

1. Step 1: Identify immutable structure traits

   Immutable means no changes allowed after creation, so no setters or public mutable fields.

2. Step 2: Match code snippet to traits

   Constant object or final class with no setters fits immutability.

3. Final Answer:

   Using a constant object or final class with no setters. -> Option A

4. Quick Check:

   Immutable = constant, no setters [OK]

Hint: Immutable means no setters or public mutable fields [OK]

Common Mistakes:

• Choosing mutable lists or global variables
• Confusing final keyword with mutable fields
• Ignoring setters in class design

3. Consider this pseudo-code snippet for an immutable user profile object:

user = ImmutableUser(name='Alice', age=30)
user.age = 31
print(user.age)

What will be the output?

medium

A. 31

B. None

C. 30

D. Error: Cannot modify immutable object

Solution

1. Step 1: Understand immutability effect on assignment

   Immutable objects do not allow changing fields after creation.

2. Step 2: Analyze the assignment line

   Trying to assign user.age = 31 will cause an error because the object is immutable.

3. Final Answer:

   Error: Cannot modify immutable object -> Option D

4. Quick Check:

   Immutable object modification = Error [OK]

Hint: Immutable objects throw error on field change [OK]

Common Mistakes:

• Assuming value silently changes
• Assuming old value prints without error
• Ignoring immutability enforcement

4. You have a mutable shared configuration object causing race conditions in a concurrent system. Which fix uses immutability to solve this?

medium

A. Add locks around every access to the mutable object.

B. Replace the shared object with an immutable configuration instance passed by value.

C. Allow threads to modify the shared object but reset it periodically.

D. Use global variables to store configuration for faster access.

Solution

1. Step 1: Identify immutability benefit in concurrency

   Immutable objects prevent race conditions by disallowing changes.

2. Step 2: Choose solution using immutability

   Replacing shared mutable object with immutable instance passed by value avoids conflicts.

3. Final Answer:

   Replace the shared object with an immutable configuration instance passed by value. -> Option B

4. Quick Check:

   Immutability fixes race conditions [OK]

Hint: Immutable shared data avoids race conditions [OK]

Common Mistakes:

• Relying only on locks without immutability
• Allowing mutable shared state
• Using global variables increases risk

5. In a complex system, you want to safely share user session data across multiple services without accidental modification. Which design approach best uses immutability for safety?

hard

A. Create immutable session objects and pass copies to each service.

B. Use a single mutable session object shared globally with synchronization.

C. Store session data in a database and allow services to update it directly.

D. Send session data as plain text strings and let services parse and modify.

Solution

1. Step 1: Understand immutability in distributed systems

   Immutable objects prevent accidental changes when shared across services.

2. Step 2: Evaluate design options

   Passing immutable session copies ensures safety without synchronization overhead.

3. Final Answer:

   Create immutable session objects and pass copies to each service. -> Option A

4. Quick Check:

   Immutable copies for safe sharing [OK]

Hint: Pass immutable copies to avoid accidental changes [OK]

Common Mistakes:

• Using mutable shared objects with locks
• Allowing direct database updates without control
• Parsing and modifying plain text increases errors