Thread safety in design in LLD - System Design Guide

Problem Statement

When multiple threads access shared data or resources without coordination, data corruption, race conditions, and unpredictable behavior occur. This leads to bugs that are hard to reproduce and fix, causing system crashes or incorrect results.

Solution

Thread safety ensures that shared data is accessed and modified in a controlled way so that only one thread can change it at a time or changes are done atomically. This is done by using locks, synchronization primitives, or designing immutable data structures to prevent conflicts and keep data consistent.

Architecture

Thread 1

→Lock/Mutex

↓

Thread 2

─────────────┘

↓

Thread Safety

Thread Safety

This diagram shows multiple threads accessing a shared resource through a lock or mutex to ensure only one thread modifies the resource at a time, enforcing thread safety.

Trade-offs

✓ Pros

→

Prevents data corruption and race conditions by controlling concurrent access.

→

Makes system behavior predictable and easier to debug.

→

Enables safe parallel execution improving performance on multi-core systems.

✗ Cons

→

Introduces complexity in code design and debugging.

→

Can cause performance overhead due to locking and context switching.

→

Risk of deadlocks if locks are not managed carefully.

Use thread safety when multiple threads or processes access shared mutable data or resources concurrently, especially in systems with high parallelism or critical data consistency requirements.

Avoid complex thread safety mechanisms when the system is single-threaded or when shared data access is minimal and can be serialized without performance impact.

Real World Examples

Google

Google's search engine uses thread-safe caches to allow multiple threads to read and update cached data without corrupting the cache state.

Netflix

Netflix uses thread-safe data structures in their streaming service backend to handle millions of concurrent user requests without data races.

LinkedIn

LinkedIn employs thread safety in their messaging system to ensure message queues are updated correctly when accessed by multiple threads.

Code Example

The before code increments a shared counter without any synchronization, causing race conditions and incorrect results. The after code uses a lock to ensure only one thread increments the counter at a time, making the operation thread-safe and the final count correct.

LLD

### Before (no thread safety, race condition possible)
import threading

class Counter:
    def __init__(self):
        self.value = 0

    def increment(self):
        self.value += 1

counter = Counter()

def worker():
    for _ in range(100000):
        counter.increment()

threads = [threading.Thread(target=worker) for _ in range(2)]
for t in threads:
    t.start()
for t in threads:
    t.join()

print(counter.value)  # Output may be less than 200000 due to race conditions


### After (with thread safety using Lock)
import threading

class Counter:
    def __init__(self):
        self.value = 0
        self.lock = threading.Lock()

    def increment(self):
        with self.lock:
            self.value += 1

counter = Counter()

def worker():
    for _ in range(100000):
        counter.increment()

threads = [threading.Thread(target=worker) for _ in range(2)]
for t in threads:
    t.start()
for t in threads:
    t.join()

print(counter.value)  # Output will reliably be 200000

Alternatives

Immutable Data Structures

Instead of locking, data is never changed after creation, so threads can read safely without synchronization.

Use when: Choose when the system can tolerate creating new copies of data rather than modifying in place, reducing locking overhead.

Actor Model

Encapsulates state inside actors that process messages sequentially, avoiding shared state and locks.

Use when: Choose when designing highly concurrent systems that benefit from message passing and isolated state.

Summary

Thread safety prevents data corruption and unpredictable behavior when multiple threads access shared resources.

It is achieved by controlling access using locks, synchronization, or immutable data.

Proper thread safety design balances correctness with performance and avoids deadlocks.

Practice

1. What does thread safety in system design primarily ensure?

easy

A. Multiple threads can access shared data without causing errors

B. The system runs faster by using more threads

C. Only one thread runs at a time in the entire system

D. Threads do not use any shared resources

Solution

1. Step 1: Understand thread safety concept

   Thread safety means multiple threads can work with shared data without causing conflicts or errors.

2. Step 2: Analyze options

   Multiple threads can access shared data without causing errors correctly states this. Options B, C, and D misunderstand thread safety or describe unrelated concepts.

3. Final Answer:

   Multiple threads can access shared data without causing errors -> Option A

4. Quick Check:

   Thread safety = safe shared data access [OK]

Hint: Thread safety means safe shared data access [OK]

Common Mistakes:

• Confusing thread safety with performance
• Thinking only one thread runs at a time
• Assuming no shared data is used

2. Which of the following is the correct way to declare a lock object in a typical low-level design for thread safety?

easy

A. lock = synchronized()

B. lock = new Lock()

C. lock = create_lock()

D. lock = Lock()

Solution

1. Step 1: Identify common lock declaration syntax

   In many low-level designs, a lock is created by calling a constructor like Lock().

2. Step 2: Compare options

   lock = Lock() uses lock = Lock(), which is typical. lock = new Lock() uses 'new' which is not common in low-level design languages. lock = create_lock() and D use incorrect or non-standard functions.

3. Final Answer:

   lock = Lock() -> Option D

4. Quick Check:

   Lock creation = Lock() [OK]

Hint: Lock objects are usually created by calling Lock() [OK]

Common Mistakes:

• Using 'new' keyword incorrectly
• Assuming lock creation uses special functions
• Confusing lock with synchronization keyword

3. Consider this pseudocode for a shared counter increment:

lock.acquire()
counter = counter + 1
lock.release()
print(counter)

If two threads run this code simultaneously starting with counter = 0, what is the possible output?

medium

A. 0

B. 3

C. 2

D. Any number greater than 2

Solution

1. Step 1: Understand lock usage in code

   The lock ensures only one thread increments the counter at a time, preventing race conditions.

2. Step 2: Calculate final counter value

   Two threads each increment once, so counter goes from 0 to 2 safely.

3. Final Answer:

   2 -> Option C

4. Quick Check:

   Lock ensures increments are safe, so counter = 2 [OK]

Hint: Locks prevent lost updates, so increments add up [OK]

Common Mistakes:

• Ignoring lock and assuming race condition
• Thinking output can be 0 or 1 due to concurrency
• Assuming counter can exceed 2 without loops

4. In this code snippet, what is the main thread safety issue?

lock.acquire()
shared_list.append(1)
# Missing lock.release()

medium

A. No issue, code is safe

B. Deadlock due to missing lock release

C. Syntax error in lock usage

D. Race condition on shared_list

Solution

1. Step 1: Analyze lock usage

   The code acquires a lock but never releases it, causing other threads to wait forever.

2. Step 2: Identify consequence

   This causes a deadlock, where threads block indefinitely waiting for the lock.

3. Final Answer:

   Deadlock due to missing lock release -> Option B

4. Quick Check:

   Missing release = deadlock [OK]

Hint: Always release locks to avoid deadlocks [OK]

Common Mistakes:

• Thinking race condition occurs despite lock
• Assuming syntax error without checking code
• Believing code is safe without release

5. You design a system where multiple threads update a shared cache. To improve performance, you want to minimize locking time. Which design approach best balances thread safety and performance?

hard

A. Use fine-grained locks for each cache entry

B. Avoid locks and allow unsynchronized updates

C. Use a single global lock for all cache updates

D. Lock the entire cache for every read and write

Solution

1. Step 1: Understand locking strategies

   A single global lock (Use a single global lock for all cache updates) causes contention and slows performance. No locks (Avoid locks and allow unsynchronized updates) risks data corruption. Locking entire cache for reads and writes (Lock the entire cache for every read and write) is too heavy.

2. Step 2: Choose fine-grained locks

   Fine-grained locks (Use fine-grained locks for each cache entry) lock only parts of the cache, reducing waiting time and keeping thread safety.

3. Final Answer:

   Use fine-grained locks for each cache entry -> Option A

4. Quick Check:

   Fine-grained locks = safety + speed [OK]

Hint: Fine-grained locks reduce wait and keep safety [OK]

Common Mistakes:

• Using one big lock causing slowdowns
• Skipping locks causing data errors
• Locking too much causing bottlenecks