System Design LLDCaching in Object Design

Caching in Object Design

LevelIntermediate

Duration60 mins

TopicCaching in Object Design

2 / 4

Lazy Loading with Caching

Deferring Work Until Absolutely Necessary

Every application loads data that users never access. Database queries fetch related records that go unread. API responses include nested objects that are never rendered. This eager loading of potentially unused data wastes bandwidth, memory, and processing time.

Lazy loading defers computation or data retrieval until the moment it's actually needed. When combined with caching, lazy loading becomes even more powerful: you not only defer the work but also ensure that once performed, the work is never repeated unnecessarily.

This combination—lazy initialization with cached results—is a foundational pattern in high-performance object-oriented design. It appears in ORMs (lazy-loaded relationships), UI frameworks (virtual scrolling), dependency injection containers, and countless domain-specific implementations.

What You Will Learn

By the end of this page, you will understand the lazy loading pattern and its variations, implement lazy-cached properties in object-oriented designs, recognize when lazy loading improves versus harms performance, and handle the complexities of lazy loading in concurrent environments.

Understanding Lazy Loading

Lazy loading is a design pattern that delays the initialization of an object or computation until it's first accessed. The opposite approach—eager loading—initializes everything upfront, regardless of whether it will be used.

The Core Principle:

Lazy loading follows a simple contract: "Don't pay for what you don't use." This principle becomes critical when:

When Lazy Loading Provides Maximum Benefit

•Initialization is expensive — Database queries, file I/O, network requests, or heavy computations
•Not all data is always needed — Optional relationships, rarely-accessed properties, conditional features
•Startup time matters — Applications that must appear responsive quickly while loading background data
•Memory is constrained — Mobile apps or embedded systems where loading everything isn't feasible
•Data may change — Deferring load ensures you get current data when accessed, not stale data from startup

Eager vs. Lazy Loading Comparison:

Loading Strategy Comparison
Aspect	Eager Loading	Lazy Loading
Initialization	All at once, upfront	On-demand, when accessed
Startup time	Slower (loads everything)	Faster (loads nothing)
First access time	Immediate (already loaded)	Slower (triggers load)
Memory usage	Higher (all data resident)	Lower (only used data)
Predictability	Consistent performance	Variable (cold vs. warm)
N+1 query risk	None (batch loading)	High (individual loads)

Implementing Lazy-Cached Properties

The most common form of lazy loading with caching is the lazy-cached property: a property that computes its value on first access and then caches it for subsequent accesses.

Basic Lazy Property Pattern:

lazy-property-basic.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
class User {
    private _profileCache: UserProfile | null = null;
    private _profileLoaded: boolean = false;
    
    constructor(
        public readonly id: string,
        public readonly email: string,
        private readonly profileRepository: ProfileRepository
    ) {}
    
    // Lazy-cached property with explicit null handling
    get profile(): UserProfile | null {
        if (!this._profileLoaded) {
            this._profileCache = this.profileRepository.findByUserId(this.id);
            this._profileLoaded = true;
        }
        return this._profileCache;
    }
}
 
// Usage
const user = new User('123', 'user@example.com', profileRepo);
// Profile not loaded yet - no database query
 
console.log(user.email);  // Immediate - no lazy loading
// Profile still not loaded
 
console.log(user.profile?.displayName);  // NOW profile loads
// Subsequent accesses use cache
console.log(user.profile?.avatar);  // No new query

Generic Lazy<T> Container:

For cleaner, reusable lazy loading, encapsulate the pattern in a dedicated container:

lazy-container.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
class Lazy<T> {
    private _value: T | undefined;
    private _initialized: boolean = false;
    
    constructor(private readonly factory: () => T) {}
    
    get value(): T {
        if (!this._initialized) {
            this._value = this.factory();
            this._initialized = true;
        }
        return this._value!;
    }
    
    get isInitialized(): boolean {
        return this._initialized;
    }
    
    // Allow resetting for cache invalidation
    reset(): void {
        this._value = undefined;
        this._initialized = false;
    }
}
 
// Async variant
class AsyncLazy<T> {
    private _promise: Promise<T> | null = null;
    private _value: T | undefined;
    private _resolved: boolean = false;
    
    constructor(private readonly factory: () => Promise<T>) {}
    
    async getValue(): Promise<T> {
        if (this._resolved) {
            return this._value!;
        }
        
        // Cache the promise to prevent duplicate requests
        if (!this._promise) {
            this._promise = this.factory().then(value => {
                this._value = value;
                this._resolved = true;
                return value;
            });
        }
        
        return this._promise;
    }
}
 
// Usage in domain objects
class Order {
    private _customer: Lazy<Customer>;
    private _items: AsyncLazy<OrderItem[]>;
    
    constructor(
        public readonly id: string,
        private readonly customerRepo: CustomerRepository,
        private readonly itemsRepo: OrderItemRepository
    ) {
        this._customer = new Lazy(() => 
            this.customerRepo.findById(this.customerId)
        );
        this._items = new AsyncLazy(() => 
            this.itemsRepo.findByOrderId(this.id)
        );
    }
    
    get customer(): Customer {
        return this._customer.value;
    }
    
    async getItems(): Promise<OrderItem[]> {
        return this._items.getValue();
    }
}

Lazy Loading in ORM Patterns

Object-Relational Mappers (ORMs) extensively use lazy loading for relationship navigation. When you access a related entity, the ORM transparently executes the necessary query.

Virtual Proxy Pattern:

ORMs often implement lazy loading through a Virtual Proxy—an object that stands in for the real entity until access triggers loading:

virtual-proxy.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// Interface for the domain object
interface Customer {
    id: string;
    name: string;
    email: string;
    orders: Order[];
}
 
// Virtual proxy that loads on access
class CustomerProxy implements Customer {
    private _realCustomer: Customer | null = null;
    
    constructor(
        public readonly id: string,
        private readonly loader: (id: string) => Customer
    ) {}
    
    private ensureLoaded(): Customer {
        if (!this._realCustomer) {
            console.log(`Loading customer ${this.id}...`);
            this._realCustomer = this.loader(this.id);
        }
        return this._realCustomer;
    }
    
    get name(): string {
        return this.ensureLoaded().name;
    }
    
    get email(): string {
        return this.ensureLoaded().email;
    }
    
    get orders(): Order[] {
        return this.ensureLoaded().orders;
    }
}
 
// ORM returns proxy, not real object
class OrderRepository {
    findById(id: string): Order {
        const row = this.db.query('SELECT * FROM orders WHERE id = ?', id);
        
        return {
            id: row.id,
            total: row.total,
            // Return proxy instead of loading customer immediately
            customer: new CustomerProxy(
                row.customer_id,
                (id) => this.customerRepo.findById(id)
            )
        };
    }
}

The N+1 Query Problem

Lazy loading's biggest pitfall is the N+1 problem: loading a list of N items, then triggering N additional queries when accessing a lazy property on each. For 100 orders, this means 101 queries instead of 2. Always consider eager loading when iterating over collections.

n-plus-one.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// ❌ N+1 Problem - 101 queries for 100 orders
const orders = await orderRepository.findAll();  // 1 query
for (const order of orders) {
    console.log(order.customer.name);  // 100 queries!
}
 
// ✅ Eager loading - 2 queries total
const orders = await orderRepository.findAllWithCustomers();  // 2 queries
for (const order of orders) {
    console.log(order.customer.name);  // Already loaded
}
 
// ✅ Batch loading - 2 queries with explicit control
const orders = await orderRepository.findAll();
const customerIds = orders.map(o => o.customerId);
const customers = await customerRepository.findByIds(customerIds);
const customerMap = new Map(customers.map(c => [c.id, c]));
 
for (const order of orders) {
    const customer = customerMap.get(order.customerId);
    console.log(customer?.name);
}

Thread Safety and Concurrency

In concurrent environments, naive lazy loading creates race conditions. Multiple threads may simultaneously detect the uninitialized state and trigger redundant computations—or worse, observe partially initialized state.

Double-Checked Locking Pattern:

thread-safe-lazy.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Thread-safe lazy initialization (conceptual - TypeScript is single-threaded)
// This pattern is critical in Java, C#, Go, etc.
 
class ThreadSafeLazy<T> {
    private value: T | null = null;
    private initialized: boolean = false;
    private readonly lock = new Mutex();
    
    constructor(private readonly factory: () => T) {}
    
    getValue(): T {
        // First check without lock (fast path)
        if (this.initialized) {
            return this.value!;
        }
        
        // Acquire lock for initialization
        return this.lock.runExclusive(() => {
            // Double-check after acquiring lock
            if (!this.initialized) {
                this.value = this.factory();
                this.initialized = true;
            }
            return this.value!;
        });
    }
}
 
// Modern approach: Promise-based for async contexts
class AsyncCachingLoader<T> {
    private promise: Promise<T> | null = null;
    
    constructor(private readonly loader: () => Promise<T>) {}
    
    async load(): Promise<T> {
        // Cache the promise itself, not just the result
        // This prevents duplicate in-flight requests
        if (!this.promise) {
            this.promise = this.loader();
        }
        return this.promise;
    }
    
    invalidate(): void {
        this.promise = null;
    }
}

Cache the Promise, Not the Result

In async contexts, always cache the Promise object rather than waiting for its resolution before caching. This ensures that concurrent callers receive the same Promise, preventing duplicate requests even when the first request is still in flight.

Best Practices and Guidelines

When to Use Lazy Loading

•Expensive initialization that may not be needed
•Optional relationships or properties
•Large object graphs with conditional access
•Improving perceived startup time
•Memory-constrained environments

When to Avoid Lazy Loading

•Data will definitely be accessed immediately
•Inside loops (N+1 problem)
•When predictable timing is critical
•Simple, cheap computations
•When batch loading is available

Implementation Guidelines

•Make lazy loading explicit — Document which properties are lazy to help consumers avoid N+1 patterns
•Provide eager loading alternatives — Offer methods like loadWithRelations() for batch scenarios
•Implement cache invalidation — Allow resetting lazy properties when underlying data changes
•Handle errors gracefully — Decide whether to cache failures or retry on next access
•Monitor cache effectiveness — Track hit rates to verify lazy loading provides actual benefit

Page Complete

You now understand lazy loading with caching—how to defer expensive work until needed and ensure it's never repeated unnecessarily. Next, we'll explore caching computed properties, where derived values are calculated once and cached to avoid redundant recalculation.

2 / 4

Loading learning content...

System Design LLDCaching in Object Design

Caching in Object Design

LevelIntermediate

Duration60 mins

TopicCaching in Object Design

2 / 4

Lazy Loading with Caching

Deferring Work Until Absolutely Necessary

What You Will Learn

Understanding Lazy Loading

The Core Principle:

Lazy loading follows a simple contract: "Don't pay for what you don't use." This principle becomes critical when:

When Lazy Loading Provides Maximum Benefit

•Initialization is expensive — Database queries, file I/O, network requests, or heavy computations
•Not all data is always needed — Optional relationships, rarely-accessed properties, conditional features
•Startup time matters — Applications that must appear responsive quickly while loading background data
•Memory is constrained — Mobile apps or embedded systems where loading everything isn't feasible
•Data may change — Deferring load ensures you get current data when accessed, not stale data from startup

Eager vs. Lazy Loading Comparison:

Loading Strategy Comparison
Aspect	Eager Loading	Lazy Loading
Initialization	All at once, upfront	On-demand, when accessed
Startup time	Slower (loads everything)	Faster (loads nothing)
First access time	Immediate (already loaded)	Slower (triggers load)
Memory usage	Higher (all data resident)	Lower (only used data)
Predictability	Consistent performance	Variable (cold vs. warm)
N+1 query risk	None (batch loading)	High (individual loads)

Implementing Lazy-Cached Properties

The most common form of lazy loading with caching is the lazy-cached property: a property that computes its value on first access and then caches it for subsequent accesses.

Basic Lazy Property Pattern:

lazy-property-basic.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
class User {
    private _profileCache: UserProfile | null = null;
    private _profileLoaded: boolean = false;
    
    constructor(
        public readonly id: string,
        public readonly email: string,
        private readonly profileRepository: ProfileRepository
    ) {}
    
    // Lazy-cached property with explicit null handling
    get profile(): UserProfile | null {
        if (!this._profileLoaded) {
            this._profileCache = this.profileRepository.findByUserId(this.id);
            this._profileLoaded = true;
        }
        return this._profileCache;
    }
}
 
// Usage
const user = new User('123', 'user@example.com', profileRepo);
// Profile not loaded yet - no database query
 
console.log(user.email);  // Immediate - no lazy loading
// Profile still not loaded
 
console.log(user.profile?.displayName);  // NOW profile loads
// Subsequent accesses use cache
console.log(user.profile?.avatar);  // No new query

Generic Lazy<T> Container:

For cleaner, reusable lazy loading, encapsulate the pattern in a dedicated container:

lazy-container.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
class Lazy<T> {
    private _value: T | undefined;
    private _initialized: boolean = false;
    
    constructor(private readonly factory: () => T) {}
    
    get value(): T {
        if (!this._initialized) {
            this._value = this.factory();
            this._initialized = true;
        }
        return this._value!;
    }
    
    get isInitialized(): boolean {
        return this._initialized;
    }
    
    // Allow resetting for cache invalidation
    reset(): void {
        this._value = undefined;
        this._initialized = false;
    }
}
 
// Async variant
class AsyncLazy<T> {
    private _promise: Promise<T> | null = null;
    private _value: T | undefined;
    private _resolved: boolean = false;
    
    constructor(private readonly factory: () => Promise<T>) {}
    
    async getValue(): Promise<T> {
        if (this._resolved) {
            return this._value!;
        }
        
        // Cache the promise to prevent duplicate requests
        if (!this._promise) {
            this._promise = this.factory().then(value => {
                this._value = value;
                this._resolved = true;
                return value;
            });
        }
        
        return this._promise;
    }
}
 
// Usage in domain objects
class Order {
    private _customer: Lazy<Customer>;
    private _items: AsyncLazy<OrderItem[]>;
    
    constructor(
        public readonly id: string,
        private readonly customerRepo: CustomerRepository,
        private readonly itemsRepo: OrderItemRepository
    ) {
        this._customer = new Lazy(() => 
            this.customerRepo.findById(this.customerId)
        );
        this._items = new AsyncLazy(() => 
            this.itemsRepo.findByOrderId(this.id)
        );
    }
    
    get customer(): Customer {
        return this._customer.value;
    }
    
    async getItems(): Promise<OrderItem[]> {
        return this._items.getValue();
    }
}

Lazy Loading in ORM Patterns

Object-Relational Mappers (ORMs) extensively use lazy loading for relationship navigation. When you access a related entity, the ORM transparently executes the necessary query.

Virtual Proxy Pattern:

ORMs often implement lazy loading through a Virtual Proxy—an object that stands in for the real entity until access triggers loading:

virtual-proxy.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// Interface for the domain object
interface Customer {
    id: string;
    name: string;
    email: string;
    orders: Order[];
}
 
// Virtual proxy that loads on access
class CustomerProxy implements Customer {
    private _realCustomer: Customer | null = null;
    
    constructor(
        public readonly id: string,
        private readonly loader: (id: string) => Customer
    ) {}
    
    private ensureLoaded(): Customer {
        if (!this._realCustomer) {
            console.log(`Loading customer ${this.id}...`);
            this._realCustomer = this.loader(this.id);
        }
        return this._realCustomer;
    }
    
    get name(): string {
        return this.ensureLoaded().name;
    }
    
    get email(): string {
        return this.ensureLoaded().email;
    }
    
    get orders(): Order[] {
        return this.ensureLoaded().orders;
    }
}
 
// ORM returns proxy, not real object
class OrderRepository {
    findById(id: string): Order {
        const row = this.db.query('SELECT * FROM orders WHERE id = ?', id);
        
        return {
            id: row.id,
            total: row.total,
            // Return proxy instead of loading customer immediately
            customer: new CustomerProxy(
                row.customer_id,
                (id) => this.customerRepo.findById(id)
            )
        };
    }
}

The N+1 Query Problem

n-plus-one.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// ❌ N+1 Problem - 101 queries for 100 orders
const orders = await orderRepository.findAll();  // 1 query
for (const order of orders) {
    console.log(order.customer.name);  // 100 queries!
}
 
// ✅ Eager loading - 2 queries total
const orders = await orderRepository.findAllWithCustomers();  // 2 queries
for (const order of orders) {
    console.log(order.customer.name);  // Already loaded
}
 
// ✅ Batch loading - 2 queries with explicit control
const orders = await orderRepository.findAll();
const customerIds = orders.map(o => o.customerId);
const customers = await customerRepository.findByIds(customerIds);
const customerMap = new Map(customers.map(c => [c.id, c]));
 
for (const order of orders) {
    const customer = customerMap.get(order.customerId);
    console.log(customer?.name);
}

Thread Safety and Concurrency

Double-Checked Locking Pattern:

thread-safe-lazy.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Thread-safe lazy initialization (conceptual - TypeScript is single-threaded)
// This pattern is critical in Java, C#, Go, etc.
 
class ThreadSafeLazy<T> {
    private value: T | null = null;
    private initialized: boolean = false;
    private readonly lock = new Mutex();
    
    constructor(private readonly factory: () => T) {}
    
    getValue(): T {
        // First check without lock (fast path)
        if (this.initialized) {
            return this.value!;
        }
        
        // Acquire lock for initialization
        return this.lock.runExclusive(() => {
            // Double-check after acquiring lock
            if (!this.initialized) {
                this.value = this.factory();
                this.initialized = true;
            }
            return this.value!;
        });
    }
}
 
// Modern approach: Promise-based for async contexts
class AsyncCachingLoader<T> {
    private promise: Promise<T> | null = null;
    
    constructor(private readonly loader: () => Promise<T>) {}
    
    async load(): Promise<T> {
        // Cache the promise itself, not just the result
        // This prevents duplicate in-flight requests
        if (!this.promise) {
            this.promise = this.loader();
        }
        return this.promise;
    }
    
    invalidate(): void {
        this.promise = null;
    }
}

Cache the Promise, Not the Result

Best Practices and Guidelines

When to Use Lazy Loading

•Expensive initialization that may not be needed
•Optional relationships or properties
•Large object graphs with conditional access
•Improving perceived startup time
•Memory-constrained environments

When to Avoid Lazy Loading

•Data will definitely be accessed immediately
•Inside loops (N+1 problem)
•When predictable timing is critical
•Simple, cheap computations
•When batch loading is available

Implementation Guidelines

•Make lazy loading explicit — Document which properties are lazy to help consumers avoid N+1 patterns
•Provide eager loading alternatives — Offer methods like loadWithRelations() for batch scenarios
•Implement cache invalidation — Allow resetting lazy properties when underlying data changes
•Handle errors gracefully — Decide whether to cache failures or retry on next access
•Monitor cache effectiveness — Track hit rates to verify lazy loading provides actual benefit

Page Complete

2 / 4