System Design (LLD)Resource Management

What Is Resource Management?

LevelIntermediate

Duration60 mins

TopicResource Management

3 / 4

Resource Lifecycle

The Journey of Every Resource

Every resource has a lifecycle—a predictable journey from creation to destruction. Understanding this lifecycle is fundamental to resource management because correct management means honoring the lifecycle invariants at every phase.

The lifecycle concept is universal. Whether you're dealing with a file handle, a database connection, a GPU texture, or a distributed lock, the same abstract phases apply. Mastering the lifecycle means you can reason about any resource, even ones you've never encountered before.

This page provides a detailed examination of each lifecycle phase, the state transitions between them, and the patterns that ensure resources are managed correctly throughout their existence.

What You Will Learn

By the end of this page, you will understand: (1) The three primary lifecycle phases and their responsibilities, (2) Valid and invalid state transitions, (3) Error handling at each phase, (4) The role of ownership in lifecycle management, and (5) Common lifecycle anti-patterns to avoid.

The Three Phases

At its core, every resource lifecycle consists of three phases:

Phase 1: Acquisition (Creation/Opening)

The resource is obtained from the external system. This phase:

Requests the resource from the provider (OS, database, service)
May involve authentication, negotiation, or allocation
Returns a handle/reference if successful
May fail if the resource is unavailable or limits are exceeded

Phase 2: Usage (Active)

The resource is actively used for its intended purpose. This phase:

Performs operations through the resource (read, write, query)
May modify resource state (file position, connection session)
Must respect resource semantics (thread-safety, protocol)
Can encounter errors during operation

Phase 3: Release (Disposal/Closing)

The resource is returned to the provider. This phase:

Flushes any pending operations (buffered writes)
Notifies the provider the resource is no longer needed
Releases associated memory and kernel structures
Makes the resource available for other users

┌─────────────────────────────────────────────────────────────────────┐
│                      RESOURCE LIFECYCLE                              │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐     │
│   │              │      │              │      │              │     │
│   │  ACQUISITION │─────►│    USAGE     │─────►│   RELEASE    │     │
│   │              │      │              │      │              │     │
│   └──────────────┘      └──────────────┘      └──────────────┘     │
│                                                                     │
│   • Request resource     • Perform operations  • Flush buffers     │
│   • Authenticate         • Handle errors       • Notify provider   │
│   • Negotiate            • Respect semantics   • Free memory       │
│   • Handle failure       • Maintain validity   • Return to pool    │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

The Lifecycle Invariant

The fundamental lifecycle invariant: Usage may only occur between Acquisition and Release. Every use of a resource must be preceded by successful acquisition and followed (eventually) by release. Any violation—use before acquire, use after release, or missing release—is a bug.

Acquisition Phase Deep Dive

The acquisition phase establishes the resource and determines whether its use is possible. This phase carries significant complexity because acquisition can fail in numerous ways, and each failure mode requires different handling.

Acquisition patterns:

1. Direct Acquisition

You explicitly request the resource:

open(path, mode) → file handle
new Connection(config) → connection object
lock.acquire() → lock grant

Direct acquisition gives you full control but full responsibility.

2. Pool-Based Acquisition

You borrow from a pre-created pool:

pool.getConnection() → borrowed connection
pool.acquire() → borrowed worker

Pool acquisition may block if pool is exhausted, or fail with timeout.

3. Lazy Acquisition

Resource acquired on first use:

Database connection on first query
File opened on first read

Lazy acquisition simplifies client code but complicates error handling—acquisition errors occur at unexpected points.

4. Factory Acquisition

A factory method encapsulates acquisition logic:

connectionFactory.createConnection()
resourceManager.getOrCreate(key)

Factories can embed retry logic, configuration, and resource tracking.

Acquisition Failure Modes
Failure Mode	Example	Typical Handling
Resource not found	File doesn't exist	Report error, don't retry
Permission denied	Access control blocks	Report error, escalate if needed
Limit exceeded	Too many connections	Retry with backoff, or fail
Timeout	Connection SYN times out	Retry with backoff
Service unavailable	Database down	Retry, use fallback, or fail
Invalid parameters	Bad connection string	Report error, check config
Authentication failed	Wrong credentials	Report error, check secrets
Resource conflict	Exclusive lock held	Retry or abort depending on use case

acquisition-patterns.ts
TypeScript
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
// Direct acquisition with error handling
async function directAcquisition(path: string): Promise<FileHandle> {
    try {
        const file = await open(path, 'r');
        return file;
    } catch (error) {
        if (error.code === 'ENOENT') {
            throw new ResourceNotFoundError(`File not found: ${path}`);
        }
        if (error.code === 'EACCES') {
            throw new AccessDeniedError(`Permission denied: ${path}`);
        }
        if (error.code === 'EMFILE') {
            throw new ResourceExhaustedError('Too many open files');
        }
        throw error; // Unknown error - propagate
    }
}
 
// Pool-based acquisition with timeout
async function poolAcquisition(pool: ConnectionPool): Promise<PooledConnection> {
    const timeout = 5000; // 5 seconds
    
    try {
        const connection = await pool.acquire({ timeout });
        return connection;
    } catch (error) {
        if (error.code === 'POOL_TIMEOUT') {
            // Log for diagnostics - pool exhaustion is a serious issue
            console.error('Connection pool exhausted');
            throw new ServiceUnavailableError('Database pool exhausted');
        }
        throw error;
    }
}
 
// Factory with retry logic
class ConnectionFactory {
    async createConnection(config: ConnectionConfig): Promise<Connection> {
        const maxRetries = 3;
        const baseDelay = 100;
        
        for (let attempt = 1; attempt <= maxRetries; attempt++) {
            try {
                const connection = await this.doConnect(config);
                return connection;
            } catch (error) {
                if (attempt === maxRetries || !this.isRetryable(error)) {
                    throw error;
                }
                
                const delay = baseDelay * Math.pow(2, attempt - 1);
                await this.sleep(delay);
            }
        }
        
        throw new Error('Unreachable');
    }
    
    private isRetryable(error: Error): boolean {
        // Network errors and temporary unavailability are retryable
        return error.code === 'ECONNREFUSED' || 
               error.code === 'ETIMEDOUT' ||
               error.code === 'ECONNRESET';
    }
}

Post-Acquisition Responsibility

Once acquisition succeeds, you are responsible for eventual release. This responsibility begins immediately—even if the next line of code throws an exception. This is why try-finally patterns are essential: success at acquisition mandates release logic.

Usage Phase Deep Dive

The usage phase is where resources provide value. During this phase, you perform the operations the resource enables. But usage isn't just 'use freely'—it has rules, constraints, and error handling requirements.

Usage phase responsibilities:

1. Validity Checking

Before every operation, ensure the resource is still valid:

Connection may have been closed by remote peer
File may have been deleted or moved
Lock may have expired

2. Error Handling

Operations can fail during usage:

Network connection drops mid-query
Disk runs out of space mid-write
Remote service returns errors

Error handling during usage must not prevent release—cleanup must still occur.

3. State Management

Resources have state that changes during usage:

File position after read/write
Connection session variables
Transaction state (begun, committed)

You must track state and ensure consistency.

4. Concurrency Rules

Many resources have thread-safety rules:

Connections may not be safe to share across threads
File handles may require explicit locking for concurrent access
Some operations may block while others are in progress

usage-patterns.ts
TypeScript
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
78
79
80
81
82
83
84
85
class ConnectionWrapper {
    private connection: Connection | null = null;
    private transactionActive: boolean = false;
    
    // Check validity before every operation
    private ensureValid(): void {
        if (this.connection === null) {
            throw new InvalidStateError('Connection not acquired');
        }
        if (!this.connection.isAlive()) {
            throw new ConnectionLostError('Connection is no longer active');
        }
    }
    
    async query(sql: string, params: any[]): Promise<Result> {
        this.ensureValid();
        
        try {
            return await this.connection!.query(sql, params);
        } catch (error) {
            // Operation failed - connection may be corrupted
            if (this.isConnectionError(error)) {
                // Mark connection as invalid
                this.connection!.markBroken();
            }
            throw error;
        }
    }
    
    async beginTransaction(): Promise<void> {
        this.ensureValid();
        
        if (this.transactionActive) {
            throw new InvalidStateError('Transaction already active');
        }
        
        await this.connection!.query('BEGIN');
        this.transactionActive = true;
    }
    
    async commit(): Promise<void> {
        this.ensureValid();
        
        if (!this.transactionActive) {
            throw new InvalidStateError('No active transaction');
        }
        
        try {
            await this.connection!.query('COMMIT');
        } finally {
            this.transactionActive = false;
        }
    }
    
    async rollback(): Promise<void> {
        this.ensureValid();
        
        if (!this.transactionActive) {
            throw new InvalidStateError('No active transaction');
        }
        
        try {
            await this.connection!.query('ROLLBACK');
        } finally {
            this.transactionActive = false;
        }
    }
    
    // Transaction state affects cleanup - must rollback if active
    async release(): Promise<void> {
        if (this.connection) {
            if (this.transactionActive) {
                try {
                    await this.connection.query('ROLLBACK');
                } catch (error) {
                    // Log but continue - we must release
                    console.error('Rollback failed during release', error);
                }
            }
            
            await this.connection.close();
            this.connection = null;
        }
    }
}

Cascading resource usage:

Resources often depend on other resources during usage. A database transaction may:

Hold multiple row locks
Allocate temporary tables
Create write-ahead log entries
Reserve memory for result sets

These 'child resources' create nested cleanup obligations. Properly structured code handles these cascades automatically through compositional patterns.

Usage timeout considerations:

Long-running operations during usage can hold resources indefinitely:

Queries that run for hours
Bulk file operations
Slow network transfers

Timeouts during usage protect against resource starvation but require careful handling—you may need to abort operations or force cleanup.

Release Phase Deep Dive

The release phase completes the lifecycle by returning the resource to the provider. This phase is non-optional—skipping it causes leaks. Yet release is also the phase most frequently botched, especially in error paths.

Release phase responsibilities:

1. Flush Pending Operations

Buffered data must be written before the resource is released:

File buffers must be flushed to disk
Network buffers must be transmitted
Pending log entries must be persisted

2. Protocol Compliance

Clean shutdown often requires protocol-specific steps:

TCP: Send FIN, wait for FIN-ACK
TLS: Send close_notify
HTTP/2: Send GOAWAY
Database: End transaction, close statement

3. Cleanup of Derived Resources

Releasing a parent resource requires releasing all child resources:

Closing a directory handle should close all file iterators
Closing a connection should close all statements/cursors

Release Patterns
Pattern	Mechanism	Best For
Explicit close	`resource.close()`	Simple, clear ownership
Using/try-with-resources	Language construct	Scoped usage, automatic cleanup
Context manager	Python `with` statement	Pythonic resource handling
Pool return	`pool.release(resource)`	Pool-managed resources
Factory cleanup	`factory.destroy(resource)`	Factory-created resources
Scope-based (RAII)	Destructor on scope exit	C++, Rust
Finalizer/destructor	GC-triggered cleanup	Last resort only

release-patterns.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
// Pattern 1: Explicit try/finally
async function explicitRelease(path: string): Promise<string> {
    const file = await open(path, 'r');
    try {
        return await file.readFile('utf-8');
    } finally {
        await file.close();
    }
}
 
// Pattern 2: Using-style helper (Symbol.asyncDispose)
async function usingRelease(path: string): Promise<string> {
    await using file = await open(path, 'r');
    // file.close() called automatically when block exits
    return file.readFile('utf-8');
}
 
// Pattern 3: Wrapper that encapsulates cleanup
async function withFile<T>(
    path: string, 
    operation: (file: FileHandle) => Promise<T>
): Promise<T> {
    const file = await open(path, 'r');
    try {
        return await operation(file);
    } finally {
        await file.close();
    }
}
 
// Usage:
const content = await withFile('data.txt', async (file) => {
    return file.readFile('utf-8');
});
 
// Pattern 4: Pool release (not close!)
async function poolRelease(pool: Pool): Promise<void> {
    const conn = await pool.acquire();
    try {
        await conn.query('SELECT 1');
    } finally {
        // Return to pool, don't close!
        pool.release(conn);
    }
}

Release Must Not Throw (Usually)

Release failures are problematic because they occur in cleanup paths—often in finally blocks. If release throws, it may mask the original error. Best practice: log release failures but don't throw, or use specific exception handling that preserves the original error.

State Transitions and Validity

Resources can be modeled as state machines with well-defined states and transitions. Understanding the state machine helps prevent invalid operations and ensures correct lifecycle management.

Basic resource states:

┌─────────────────────────────────────────────────────────────────────┐
│                    RESOURCE STATE MACHINE                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   ┌──────────┐      ┌──────────┐      ┌──────────┐                 │
│   │          │      │          │      │          │                 │
│   │  UNOPEN  │──────│   OPEN   │──────│  CLOSED  │                 │
│   │          │ open │          │ close│          │                 │
│   └──────────┘      └──────────┘      └──────────┘                 │
│                          │                                          │
│                          │ error                                    │
│                          ▼                                          │
│                     ┌──────────┐                                    │
│                     │          │                                    │
│                     │  FAILED  │                                    │
│                     │          │                                    │
│                     └──────────┘                                    │
│                          │                                          │
│                          │ close                                    │
│                          ▼                                          │
│                     ┌──────────┐                                    │
│                     │          │                                    │
│                     │  CLOSED  │                                    │
│                     │          │                                    │
│                     └──────────┘                                    │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Valid transitions:

UNOPEN → OPEN: Successful acquisition
OPEN → CLOSED: Clean release
OPEN → FAILED: Error during usage
FAILED → CLOSED: Cleanup after failure

Invalid transitions:

CLOSED → OPEN: Cannot reopen closed resource (usually)
UNOPEN → CLOSED: Cannot close unopened resource
CLOSED → FAILED: Closed is terminal

resource-state-machine.ts
TypeScript
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
78
79
80
81
82
83
84
85
enum ResourceState {
    UNACQUIRED = 'UNACQUIRED',
    ACTIVE = 'ACTIVE',
    FAILED = 'FAILED',
    RELEASED = 'RELEASED',
}
 
class ManagedResource<T> {
    private state: ResourceState = ResourceState.UNACQUIRED;
    private resource: T | null = null;
    
    constructor(
        private acquire: () => Promise<T>,
        private release: (resource: T) => Promise<void>
    ) {}
    
    async open(): Promise<void> {
        // Validate transition
        if (this.state !== ResourceState.UNACQUIRED) {
            throw new InvalidStateError(
                `Cannot acquire from state ${this.state}`
            );
        }
        
        try {
            this.resource = await this.acquire();
            this.state = ResourceState.ACTIVE;
        } catch (error) {
            this.state = ResourceState.FAILED;
            throw error;
        }
    }
    
    async use<R>(operation: (resource: T) => Promise<R>): Promise<R> {
        // Validate state
        if (this.state !== ResourceState.ACTIVE) {
            throw new InvalidStateError(
                `Cannot use resource in state ${this.state}`
            );
        }
        
        try {
            return await operation(this.resource!);
        } catch (error) {
            // Optionally mark as failed based on error type
            if (this.isFatalError(error)) {
                this.state = ResourceState.FAILED;
            }
            throw error;
        }
    }
    
    async close(): Promise<void> {
        // Allow closing from ACTIVE or FAILED states
        if (this.state === ResourceState.RELEASED) {
            return; // Idempotent - already closed
        }
        
        if (this.state === ResourceState.UNACQUIRED) {
            return; // Never opened - nothing to close
        }
        
        try {
            if (this.resource) {
                await this.release(this.resource);
            }
        } finally {
            this.resource = null;
            this.state = ResourceState.RELEASED;
        }
    }
    
    get isOpen(): boolean {
        return this.state === ResourceState.ACTIVE;
    }
    
    get isClosed(): boolean {
        return this.state === ResourceState.RELEASED;
    }
    
    private isFatalError(error: Error): boolean {
        // Connection reset, etc. make resource unusable
        return error.name === 'ConnectionResetError';
    }
}

Extended states for complex resources:

Some resources have more complex state machines:

Connections:

CONNECTING → OPEN → IDLE → IN_USE → IDLE → CLOSING → CLOSED

Transactions:

NONE → BEGUN → COMMITTED/ROLLED_BACK → NONE

Streams:

OPEN → HALF_CLOSED_LOCAL → CLOSED
OPEN → HALF_CLOSED_REMOTE → CLOSED

Modeling these states explicitly helps prevent invalid operations and provides clear documentation of expected behavior.

Resource Ownership

Ownership determines who is responsible for releasing a resource. Clear ownership is essential—confusion about ownership leads to either double-release (errors) or no release (leaks).

Ownership models:

1. Exclusive Ownership

Exactly one entity owns the resource:

The owner is responsible for release
Ownership may be transferred (move semantics)
No sharing—single point of responsibility

This is the simplest and safest model.

2. Reference Counting

Multiple entities share ownership:

Reference count tracks number of owners
Resource released when count reaches zero
Each owner must properly increment/decrement

Used by smart pointers (shared_ptr), COM objects, and some language runtimes.

3. Borrowed References

One entity owns, others borrow:

Borrowers don't release—only the owner does
Borrowers must not outlive the owner
Common in function call patterns

4. Pool Ownership

Pool owns resources, clients borrow:

Pool creates and destroys resources
Clients acquire/release (borrow/return)
Pool handles lifecycle; client handles duration of borrow

ownership-patterns.ts
TypeScript
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
// Exclusive ownership - caller owns the result
async function createExclusiveConnection(): Promise<Connection> {
    // Caller receives ownership - caller must close
    return await Connection.create(config);
}
 
// Usage - caller is responsible
async function useExclusiveOwnership(): Promise<void> {
    const conn = await createExclusiveConnection();
    try {
        // Use connection
    } finally {
        await conn.close(); // Our responsibility
    }
}
 
// Borrowed reference - callee uses, caller owns
async function queryWithBorrowed(
    conn: Connection,  // Borrowed - we don't own it
    sql: string
): Promise<Result> {
    // Use connection, but don't close it
    return conn.query(sql);
    // No close() here - we don't own it
}
 
// Pool ownership - pool owns, we borrow
async function poolPattern(pool: ConnectionPool): Promise<void> {
    const conn = await pool.acquire(); // Borrow
    try {
        await conn.query('SELECT 1');
    } finally {
        pool.release(conn); // Return borrow, don't close
    }
}
 
// Factory with ownership transfer
class ConnectionFactory {
    create(): Connection {
        const conn = new Connection();
        // Caller takes ownership - we're done
        return conn;
    }
    
    // Alternatively: managed creation with callback (no transfer)
    async withConnection<T>(
        operation: (conn: Connection) => Promise<T>
    ): Promise<T> {
        const conn = new Connection();
        try {
            return await operation(conn); // Borrower uses
        } finally {
            await conn.close(); // We own, we release
        }
    }
}

Clear Ownership Through Documentation

Make ownership explicit in documentation and naming. Method names like createConnection() suggest caller takes ownership. Parameters named borrowedConn or return types like OwnedHandle make ownership clear. When in doubt, document who is responsible for release.

Ownership Do's

•Document ownership transfer explicitly
•Use naming conventions (create/borrow)
•Return owned resources from factories
•Pass borrowed resources as parameters
•Use type systems (Rust) where available

Ownership Don'ts

•Unclear who releases shared resources
•Storing borrowed refs beyond owner lifetime
•Double-release by multiple 'owners'
•Assuming GC handles resource release
•Mixing ownership models inconsistently

Lifecycle Anti-Patterns

Certain patterns reliably cause lifecycle bugs. Recognizing these anti-patterns helps you avoid them in your own code and identify them in code review.

Anti-Pattern 1: The Forgotten Finally

Release code exists but isn't guaranteed to run:

anti-patterns.ts
TypeScript
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
// ❌ Anti-Pattern 1: Forgotten finally
async function forgottenFinally(): Promise<void> {
    const conn = await pool.acquire();
    
    const result = await conn.query('SELECT * FROM users');
    
    if (result.rows.length === 0) {
        return; // Early return - release skipped!
    }
    
    processUsers(result.rows);
    
    pool.release(conn); // Never reached on early return
}
 
// ❌ Anti-Pattern 2: Release in wrong scope
async function wrongScope(): Promise<void> {
    let conn: Connection | null = null;
    
    if (needsDatabase) {
        conn = await pool.acquire();
        await conn.query('...');
    }
    
    // conn might be null here - release may fail or be wrong
    pool.release(conn!); // Dangerous!
}
 
// ❌ Anti-Pattern 3: Async release without await
async function unawaited(): Promise<void> {
    const file = await open('data.txt', 'r');
    try {
        return file.readFile('utf-8');
    } finally {
        file.close(); // No await - close may not complete!
    }
}
 
// ❌ Anti-Pattern 4: Release-only-on-success
async function onlyOnSuccess(): Promise<void> {
    const conn = await pool.acquire();
    
    try {
        await riskyOperation(conn);
        pool.release(conn); // Only on success!
    } catch (error) {
        // On error, connection never released!
        throw error;
    }
}
 
// ❌ Anti-Pattern 5: Storing resource for later
class BadCache {
    private connection?: Connection;
    
    async query(sql: string): Promise<Result> {
        // Create connection lazily and store it
        if (!this.connection) {
            this.connection = await pool.acquire();
        }
        return this.connection.query(sql);
        // When is this ever released? Never!
    }
}

Critical Lifecycle Anti-Patterns

•Forgotten Finally — Release code exists but early returns bypass it
•Wrong Scope — Release assumes acquisition but acquisition is conditional
•Unawaited Release — Async close() not awaited, cleanup may not complete
•Success-Only Release — Release in try block, not in finally
•Stored For Later — Resource saved to instance field without clear release point
•Null Check Reliance — Assuming null check prevents double-release (race conditions)
•Exception Hiding — Catch-and-ignore in code before release

The Finally Rule

If you acquire a resource, the very next line of code should be 'try {' and there should be a corresponding 'finally { release }' block. Don't do anything between acquire and try. This pattern is mechanical and fool-proof.

Summary: The Resource Lifecycle

The resource lifecycle—acquisition, usage, release—is the foundation of all resource management. Let's consolidate what we've learned:

Key Takeaways

•Three phases govern every resource: Acquisition, Usage, Release—in that order, without exception.
•Acquisition can fail in many ways — Design for failure at creation, not just during use.
•Usage must respect resource state — Validate before operations, handle errors, track state changes.
•Release is non-optional — Every acquisition creates a release obligation that must be honored.
•State machines model valid transitions — Invalid transitions indicate bugs; model them explicitly.
•Clear ownership prevents bugs — Every resource should have exactly one owner responsible for release.
•Anti-patterns are recognizable — Learn to spot forgotten-finally, wrong-scope, and stored-for-later patterns.

What's next:

Now that we understand the lifecycle, we'll explore why resource management matters—the real-world consequences of resource mismanagement, from memory leaks to production outages to financial costs.

Page Complete

You now have a deep understanding of the resource lifecycle and its phases. This knowledge enables you to design resource-handling code that correctly manages resources through their entire journey, from acquisition to release. Next, we'll see why this matters in real systems.

3 / 4

Loading learning content...

System Design (LLD)Resource Management

What Is Resource Management?

LevelIntermediate

Duration60 mins

TopicResource Management

3 / 4

Resource Lifecycle

The Journey of Every Resource

This page provides a detailed examination of each lifecycle phase, the state transitions between them, and the patterns that ensure resources are managed correctly throughout their existence.

What You Will Learn

The Three Phases

At its core, every resource lifecycle consists of three phases:

Phase 1: Acquisition (Creation/Opening)

The resource is obtained from the external system. This phase:

Requests the resource from the provider (OS, database, service)
May involve authentication, negotiation, or allocation
Returns a handle/reference if successful
May fail if the resource is unavailable or limits are exceeded

Phase 2: Usage (Active)

The resource is actively used for its intended purpose. This phase:

Performs operations through the resource (read, write, query)
May modify resource state (file position, connection session)
Must respect resource semantics (thread-safety, protocol)
Can encounter errors during operation

Phase 3: Release (Disposal/Closing)

The resource is returned to the provider. This phase:

Flushes any pending operations (buffered writes)
Notifies the provider the resource is no longer needed
Releases associated memory and kernel structures
Makes the resource available for other users

┌─────────────────────────────────────────────────────────────────────┐
│                      RESOURCE LIFECYCLE                              │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐     │
│   │              │      │              │      │              │     │
│   │  ACQUISITION │─────►│    USAGE     │─────►│   RELEASE    │     │
│   │              │      │              │      │              │     │
│   └──────────────┘      └──────────────┘      └──────────────┘     │
│                                                                     │
│   • Request resource     • Perform operations  • Flush buffers     │
│   • Authenticate         • Handle errors       • Notify provider   │
│   • Negotiate            • Respect semantics   • Free memory       │
│   • Handle failure       • Maintain validity   • Return to pool    │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

The Lifecycle Invariant

Acquisition Phase Deep Dive

Acquisition patterns:

1. Direct Acquisition

You explicitly request the resource:

open(path, mode) → file handle
new Connection(config) → connection object
lock.acquire() → lock grant

Direct acquisition gives you full control but full responsibility.

2. Pool-Based Acquisition

You borrow from a pre-created pool:

pool.getConnection() → borrowed connection
pool.acquire() → borrowed worker

Pool acquisition may block if pool is exhausted, or fail with timeout.

3. Lazy Acquisition

Resource acquired on first use:

Database connection on first query
File opened on first read

Lazy acquisition simplifies client code but complicates error handling—acquisition errors occur at unexpected points.

4. Factory Acquisition

A factory method encapsulates acquisition logic:

connectionFactory.createConnection()
resourceManager.getOrCreate(key)

Factories can embed retry logic, configuration, and resource tracking.

Acquisition Failure Modes
Failure Mode	Example	Typical Handling
Resource not found	File doesn't exist	Report error, don't retry
Permission denied	Access control blocks	Report error, escalate if needed
Limit exceeded	Too many connections	Retry with backoff, or fail
Timeout	Connection SYN times out	Retry with backoff
Service unavailable	Database down	Retry, use fallback, or fail
Invalid parameters	Bad connection string	Report error, check config
Authentication failed	Wrong credentials	Report error, check secrets
Resource conflict	Exclusive lock held	Retry or abort depending on use case

acquisition-patterns.ts
TypeScript
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
// Direct acquisition with error handling
async function directAcquisition(path: string): Promise<FileHandle> {
    try {
        const file = await open(path, 'r');
        return file;
    } catch (error) {
        if (error.code === 'ENOENT') {
            throw new ResourceNotFoundError(`File not found: ${path}`);
        }
        if (error.code === 'EACCES') {
            throw new AccessDeniedError(`Permission denied: ${path}`);
        }
        if (error.code === 'EMFILE') {
            throw new ResourceExhaustedError('Too many open files');
        }
        throw error; // Unknown error - propagate
    }
}
 
// Pool-based acquisition with timeout
async function poolAcquisition(pool: ConnectionPool): Promise<PooledConnection> {
    const timeout = 5000; // 5 seconds
    
    try {
        const connection = await pool.acquire({ timeout });
        return connection;
    } catch (error) {
        if (error.code === 'POOL_TIMEOUT') {
            // Log for diagnostics - pool exhaustion is a serious issue
            console.error('Connection pool exhausted');
            throw new ServiceUnavailableError('Database pool exhausted');
        }
        throw error;
    }
}
 
// Factory with retry logic
class ConnectionFactory {
    async createConnection(config: ConnectionConfig): Promise<Connection> {
        const maxRetries = 3;
        const baseDelay = 100;
        
        for (let attempt = 1; attempt <= maxRetries; attempt++) {
            try {
                const connection = await this.doConnect(config);
                return connection;
            } catch (error) {
                if (attempt === maxRetries || !this.isRetryable(error)) {
                    throw error;
                }
                
                const delay = baseDelay * Math.pow(2, attempt - 1);
                await this.sleep(delay);
            }
        }
        
        throw new Error('Unreachable');
    }
    
    private isRetryable(error: Error): boolean {
        // Network errors and temporary unavailability are retryable
        return error.code === 'ECONNREFUSED' || 
               error.code === 'ETIMEDOUT' ||
               error.code === 'ECONNRESET';
    }
}

Post-Acquisition Responsibility

Usage Phase Deep Dive

Usage phase responsibilities:

1. Validity Checking

Before every operation, ensure the resource is still valid:

Connection may have been closed by remote peer
File may have been deleted or moved
Lock may have expired

2. Error Handling

Operations can fail during usage:

Network connection drops mid-query
Disk runs out of space mid-write
Remote service returns errors

Error handling during usage must not prevent release—cleanup must still occur.

3. State Management

Resources have state that changes during usage:

File position after read/write
Connection session variables
Transaction state (begun, committed)

You must track state and ensure consistency.

4. Concurrency Rules

Many resources have thread-safety rules:

Connections may not be safe to share across threads
File handles may require explicit locking for concurrent access
Some operations may block while others are in progress

usage-patterns.ts
TypeScript
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
78
79
80
81
82
83
84
85
class ConnectionWrapper {
    private connection: Connection | null = null;
    private transactionActive: boolean = false;
    
    // Check validity before every operation
    private ensureValid(): void {
        if (this.connection === null) {
            throw new InvalidStateError('Connection not acquired');
        }
        if (!this.connection.isAlive()) {
            throw new ConnectionLostError('Connection is no longer active');
        }
    }
    
    async query(sql: string, params: any[]): Promise<Result> {
        this.ensureValid();
        
        try {
            return await this.connection!.query(sql, params);
        } catch (error) {
            // Operation failed - connection may be corrupted
            if (this.isConnectionError(error)) {
                // Mark connection as invalid
                this.connection!.markBroken();
            }
            throw error;
        }
    }
    
    async beginTransaction(): Promise<void> {
        this.ensureValid();
        
        if (this.transactionActive) {
            throw new InvalidStateError('Transaction already active');
        }
        
        await this.connection!.query('BEGIN');
        this.transactionActive = true;
    }
    
    async commit(): Promise<void> {
        this.ensureValid();
        
        if (!this.transactionActive) {
            throw new InvalidStateError('No active transaction');
        }
        
        try {
            await this.connection!.query('COMMIT');
        } finally {
            this.transactionActive = false;
        }
    }
    
    async rollback(): Promise<void> {
        this.ensureValid();
        
        if (!this.transactionActive) {
            throw new InvalidStateError('No active transaction');
        }
        
        try {
            await this.connection!.query('ROLLBACK');
        } finally {
            this.transactionActive = false;
        }
    }
    
    // Transaction state affects cleanup - must rollback if active
    async release(): Promise<void> {
        if (this.connection) {
            if (this.transactionActive) {
                try {
                    await this.connection.query('ROLLBACK');
                } catch (error) {
                    // Log but continue - we must release
                    console.error('Rollback failed during release', error);
                }
            }
            
            await this.connection.close();
            this.connection = null;
        }
    }
}

Cascading resource usage:

Resources often depend on other resources during usage. A database transaction may:

Hold multiple row locks
Allocate temporary tables
Create write-ahead log entries
Reserve memory for result sets

These 'child resources' create nested cleanup obligations. Properly structured code handles these cascades automatically through compositional patterns.

Usage timeout considerations:

Long-running operations during usage can hold resources indefinitely:

Queries that run for hours
Bulk file operations
Slow network transfers

Timeouts during usage protect against resource starvation but require careful handling—you may need to abort operations or force cleanup.

Release Phase Deep Dive

Release phase responsibilities:

1. Flush Pending Operations

Buffered data must be written before the resource is released:

File buffers must be flushed to disk
Network buffers must be transmitted
Pending log entries must be persisted

2. Protocol Compliance

Clean shutdown often requires protocol-specific steps:

TCP: Send FIN, wait for FIN-ACK
TLS: Send close_notify
HTTP/2: Send GOAWAY
Database: End transaction, close statement

3. Cleanup of Derived Resources

Releasing a parent resource requires releasing all child resources:

Closing a directory handle should close all file iterators
Closing a connection should close all statements/cursors

Release Patterns
Pattern	Mechanism	Best For
Explicit close	`resource.close()`	Simple, clear ownership
Using/try-with-resources	Language construct	Scoped usage, automatic cleanup
Context manager	Python `with` statement	Pythonic resource handling
Pool return	`pool.release(resource)`	Pool-managed resources
Factory cleanup	`factory.destroy(resource)`	Factory-created resources
Scope-based (RAII)	Destructor on scope exit	C++, Rust
Finalizer/destructor	GC-triggered cleanup	Last resort only

release-patterns.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
// Pattern 1: Explicit try/finally
async function explicitRelease(path: string): Promise<string> {
    const file = await open(path, 'r');
    try {
        return await file.readFile('utf-8');
    } finally {
        await file.close();
    }
}
 
// Pattern 2: Using-style helper (Symbol.asyncDispose)
async function usingRelease(path: string): Promise<string> {
    await using file = await open(path, 'r');
    // file.close() called automatically when block exits
    return file.readFile('utf-8');
}
 
// Pattern 3: Wrapper that encapsulates cleanup
async function withFile<T>(
    path: string, 
    operation: (file: FileHandle) => Promise<T>
): Promise<T> {
    const file = await open(path, 'r');
    try {
        return await operation(file);
    } finally {
        await file.close();
    }
}
 
// Usage:
const content = await withFile('data.txt', async (file) => {
    return file.readFile('utf-8');
});
 
// Pattern 4: Pool release (not close!)
async function poolRelease(pool: Pool): Promise<void> {
    const conn = await pool.acquire();
    try {
        await conn.query('SELECT 1');
    } finally {
        // Return to pool, don't close!
        pool.release(conn);
    }
}

Release Must Not Throw (Usually)

State Transitions and Validity

Resources can be modeled as state machines with well-defined states and transitions. Understanding the state machine helps prevent invalid operations and ensures correct lifecycle management.

Basic resource states:

┌─────────────────────────────────────────────────────────────────────┐
│                    RESOURCE STATE MACHINE                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   ┌──────────┐      ┌──────────┐      ┌──────────┐                 │
│   │          │      │          │      │          │                 │
│   │  UNOPEN  │──────│   OPEN   │──────│  CLOSED  │                 │
│   │          │ open │          │ close│          │                 │
│   └──────────┘      └──────────┘      └──────────┘                 │
│                          │                                          │
│                          │ error                                    │
│                          ▼                                          │
│                     ┌──────────┐                                    │
│                     │          │                                    │
│                     │  FAILED  │                                    │
│                     │          │                                    │
│                     └──────────┘                                    │
│                          │                                          │
│                          │ close                                    │
│                          ▼                                          │
│                     ┌──────────┐                                    │
│                     │          │                                    │
│                     │  CLOSED  │                                    │
│                     │          │                                    │
│                     └──────────┘                                    │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Valid transitions:

UNOPEN → OPEN: Successful acquisition
OPEN → CLOSED: Clean release
OPEN → FAILED: Error during usage
FAILED → CLOSED: Cleanup after failure

Invalid transitions:

CLOSED → OPEN: Cannot reopen closed resource (usually)
UNOPEN → CLOSED: Cannot close unopened resource
CLOSED → FAILED: Closed is terminal

resource-state-machine.ts
TypeScript
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
78
79
80
81
82
83
84
85
enum ResourceState {
    UNACQUIRED = 'UNACQUIRED',
    ACTIVE = 'ACTIVE',
    FAILED = 'FAILED',
    RELEASED = 'RELEASED',
}
 
class ManagedResource<T> {
    private state: ResourceState = ResourceState.UNACQUIRED;
    private resource: T | null = null;
    
    constructor(
        private acquire: () => Promise<T>,
        private release: (resource: T) => Promise<void>
    ) {}
    
    async open(): Promise<void> {
        // Validate transition
        if (this.state !== ResourceState.UNACQUIRED) {
            throw new InvalidStateError(
                `Cannot acquire from state ${this.state}`
            );
        }
        
        try {
            this.resource = await this.acquire();
            this.state = ResourceState.ACTIVE;
        } catch (error) {
            this.state = ResourceState.FAILED;
            throw error;
        }
    }
    
    async use<R>(operation: (resource: T) => Promise<R>): Promise<R> {
        // Validate state
        if (this.state !== ResourceState.ACTIVE) {
            throw new InvalidStateError(
                `Cannot use resource in state ${this.state}`
            );
        }
        
        try {
            return await operation(this.resource!);
        } catch (error) {
            // Optionally mark as failed based on error type
            if (this.isFatalError(error)) {
                this.state = ResourceState.FAILED;
            }
            throw error;
        }
    }
    
    async close(): Promise<void> {
        // Allow closing from ACTIVE or FAILED states
        if (this.state === ResourceState.RELEASED) {
            return; // Idempotent - already closed
        }
        
        if (this.state === ResourceState.UNACQUIRED) {
            return; // Never opened - nothing to close
        }
        
        try {
            if (this.resource) {
                await this.release(this.resource);
            }
        } finally {
            this.resource = null;
            this.state = ResourceState.RELEASED;
        }
    }
    
    get isOpen(): boolean {
        return this.state === ResourceState.ACTIVE;
    }
    
    get isClosed(): boolean {
        return this.state === ResourceState.RELEASED;
    }
    
    private isFatalError(error: Error): boolean {
        // Connection reset, etc. make resource unusable
        return error.name === 'ConnectionResetError';
    }
}

Extended states for complex resources:

Some resources have more complex state machines:

Connections:

CONNECTING → OPEN → IDLE → IN_USE → IDLE → CLOSING → CLOSED

Transactions:

NONE → BEGUN → COMMITTED/ROLLED_BACK → NONE

Streams:

OPEN → HALF_CLOSED_LOCAL → CLOSED
OPEN → HALF_CLOSED_REMOTE → CLOSED

Modeling these states explicitly helps prevent invalid operations and provides clear documentation of expected behavior.

Resource Ownership

Ownership determines who is responsible for releasing a resource. Clear ownership is essential—confusion about ownership leads to either double-release (errors) or no release (leaks).

Ownership models:

1. Exclusive Ownership

Exactly one entity owns the resource:

The owner is responsible for release
Ownership may be transferred (move semantics)
No sharing—single point of responsibility

This is the simplest and safest model.

2. Reference Counting

Multiple entities share ownership:

Reference count tracks number of owners
Resource released when count reaches zero
Each owner must properly increment/decrement

Used by smart pointers (shared_ptr), COM objects, and some language runtimes.

3. Borrowed References

One entity owns, others borrow:

Borrowers don't release—only the owner does
Borrowers must not outlive the owner
Common in function call patterns

4. Pool Ownership

Pool owns resources, clients borrow:

Pool creates and destroys resources
Clients acquire/release (borrow/return)
Pool handles lifecycle; client handles duration of borrow

ownership-patterns.ts
TypeScript
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
// Exclusive ownership - caller owns the result
async function createExclusiveConnection(): Promise<Connection> {
    // Caller receives ownership - caller must close
    return await Connection.create(config);
}
 
// Usage - caller is responsible
async function useExclusiveOwnership(): Promise<void> {
    const conn = await createExclusiveConnection();
    try {
        // Use connection
    } finally {
        await conn.close(); // Our responsibility
    }
}
 
// Borrowed reference - callee uses, caller owns
async function queryWithBorrowed(
    conn: Connection,  // Borrowed - we don't own it
    sql: string
): Promise<Result> {
    // Use connection, but don't close it
    return conn.query(sql);
    // No close() here - we don't own it
}
 
// Pool ownership - pool owns, we borrow
async function poolPattern(pool: ConnectionPool): Promise<void> {
    const conn = await pool.acquire(); // Borrow
    try {
        await conn.query('SELECT 1');
    } finally {
        pool.release(conn); // Return borrow, don't close
    }
}
 
// Factory with ownership transfer
class ConnectionFactory {
    create(): Connection {
        const conn = new Connection();
        // Caller takes ownership - we're done
        return conn;
    }
    
    // Alternatively: managed creation with callback (no transfer)
    async withConnection<T>(
        operation: (conn: Connection) => Promise<T>
    ): Promise<T> {
        const conn = new Connection();
        try {
            return await operation(conn); // Borrower uses
        } finally {
            await conn.close(); // We own, we release
        }
    }
}

Clear Ownership Through Documentation

Ownership Do's

•Document ownership transfer explicitly
•Use naming conventions (create/borrow)
•Return owned resources from factories
•Pass borrowed resources as parameters
•Use type systems (Rust) where available

Ownership Don'ts

•Unclear who releases shared resources
•Storing borrowed refs beyond owner lifetime
•Double-release by multiple 'owners'
•Assuming GC handles resource release
•Mixing ownership models inconsistently

Lifecycle Anti-Patterns

Certain patterns reliably cause lifecycle bugs. Recognizing these anti-patterns helps you avoid them in your own code and identify them in code review.

Anti-Pattern 1: The Forgotten Finally

Release code exists but isn't guaranteed to run:

anti-patterns.ts
TypeScript
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
// ❌ Anti-Pattern 1: Forgotten finally
async function forgottenFinally(): Promise<void> {
    const conn = await pool.acquire();
    
    const result = await conn.query('SELECT * FROM users');
    
    if (result.rows.length === 0) {
        return; // Early return - release skipped!
    }
    
    processUsers(result.rows);
    
    pool.release(conn); // Never reached on early return
}
 
// ❌ Anti-Pattern 2: Release in wrong scope
async function wrongScope(): Promise<void> {
    let conn: Connection | null = null;
    
    if (needsDatabase) {
        conn = await pool.acquire();
        await conn.query('...');
    }
    
    // conn might be null here - release may fail or be wrong
    pool.release(conn!); // Dangerous!
}
 
// ❌ Anti-Pattern 3: Async release without await
async function unawaited(): Promise<void> {
    const file = await open('data.txt', 'r');
    try {
        return file.readFile('utf-8');
    } finally {
        file.close(); // No await - close may not complete!
    }
}
 
// ❌ Anti-Pattern 4: Release-only-on-success
async function onlyOnSuccess(): Promise<void> {
    const conn = await pool.acquire();
    
    try {
        await riskyOperation(conn);
        pool.release(conn); // Only on success!
    } catch (error) {
        // On error, connection never released!
        throw error;
    }
}
 
// ❌ Anti-Pattern 5: Storing resource for later
class BadCache {
    private connection?: Connection;
    
    async query(sql: string): Promise<Result> {
        // Create connection lazily and store it
        if (!this.connection) {
            this.connection = await pool.acquire();
        }
        return this.connection.query(sql);
        // When is this ever released? Never!
    }
}

Critical Lifecycle Anti-Patterns

•Forgotten Finally — Release code exists but early returns bypass it
•Wrong Scope — Release assumes acquisition but acquisition is conditional
•Unawaited Release — Async close() not awaited, cleanup may not complete
•Success-Only Release — Release in try block, not in finally
•Stored For Later — Resource saved to instance field without clear release point
•Null Check Reliance — Assuming null check prevents double-release (race conditions)
•Exception Hiding — Catch-and-ignore in code before release

The Finally Rule

Summary: The Resource Lifecycle

The resource lifecycle—acquisition, usage, release—is the foundation of all resource management. Let's consolidate what we've learned:

Key Takeaways

•Three phases govern every resource: Acquisition, Usage, Release—in that order, without exception.
•Acquisition can fail in many ways — Design for failure at creation, not just during use.
•Usage must respect resource state — Validate before operations, handle errors, track state changes.
•Release is non-optional — Every acquisition creates a release obligation that must be honored.
•State machines model valid transitions — Invalid transitions indicate bugs; model them explicitly.
•Clear ownership prevents bugs — Every resource should have exactly one owner responsible for release.
•Anti-patterns are recognizable — Learn to spot forgotten-finally, wrong-scope, and stored-for-later patterns.

What's next:

Page Complete

3 / 4

What Is Resource Management? - Page 3 of 4 | OneNoughtOne