Concurrency considerations in LLD - System Design Guide

Problem Statement

When multiple parts of a program try to change the same data at the same time, it can cause errors like lost updates or inconsistent results. Without careful control, these conflicts can crash the program or produce wrong outputs.

Solution

Concurrency control uses locks, atomic operations, or coordination techniques to make sure only one part changes shared data at a time. This prevents conflicts and keeps data consistent even when many tasks run together.

Architecture

Thread 1

→Lock/Mutex

↓

Thread 2

→Lock/Mutex

This diagram shows multiple threads requesting access to shared data through a lock mechanism that ensures only one thread modifies the data at a time.

Trade-offs

✓ Pros

→

Prevents data corruption by serializing access to shared resources.

→

Ensures program correctness and predictable behavior under concurrent execution.

→

Allows safe parallelism, improving performance on multi-core systems.

✗ Cons

→

Locks can cause delays if many threads wait, reducing performance.

→

Improper use can lead to deadlocks where threads wait forever.

→

Adds complexity to program design and debugging.

Use when multiple threads or processes access and modify shared data concurrently, especially in systems with high parallelism or multi-core CPUs.

Avoid if the program is single-threaded or if data is immutable and never changed concurrently, as locking adds unnecessary overhead.

Real World Examples

Google

Google uses concurrency control in their search indexing system to safely update shared data structures while multiple processes run in parallel.

Uber

Uber applies concurrency considerations in their dispatch system to prevent conflicting updates when multiple drivers and riders interact simultaneously.

Netflix

Netflix uses concurrency control in their streaming service backend to handle many user requests updating session data without conflicts.

Code Example

The before code increments a shared counter from two threads without any control, causing race conditions and incorrect results. The after code uses a lock to ensure only one thread updates the counter at a time, preserving correctness.

LLD

import threading

# Before: No concurrency control
shared_counter = 0

def increment():
    global shared_counter
    for _ in range(100000):
        shared_counter += 1

threads = [threading.Thread(target=increment) for _ in range(2)]
for t in threads:
    t.start()
for t in threads:
    t.join()
print(f"Counter without lock: {shared_counter}")

# After: Using a lock to control concurrency
shared_counter = 0
lock = threading.Lock()

def increment_with_lock():
    global shared_counter
    for _ in range(100000):
        with lock:
            shared_counter += 1

threads = [threading.Thread(target=increment_with_lock) for _ in range(2)]
for t in threads:
    t.start()
for t in threads:
    t.join()
print(f"Counter with lock: {shared_counter}")

Alternatives

Event-driven architecture

Instead of locking, tasks communicate via events and queues, avoiding shared state.

Use when: Choose when you want to reduce locking complexity and can design around asynchronous message passing.

Immutable data structures

Data is never changed after creation, so no locks are needed.

Use when: Choose when your workload allows copying or versioning data instead of modifying it in place.

Summary

Concurrency considerations prevent errors when multiple tasks access shared data simultaneously.

Using locks or coordination ensures data consistency but can add complexity and reduce performance.

Choosing the right concurrency control depends on workload, system scale, and data access patterns.