Dependency injection framework in LLD - System Design Exercise

Design: Dependency Injection Framework

Design the core dependency injection framework including registration, resolution, lifecycle management, and error handling. Out of scope: integration with specific frameworks or languages, UI components.

Functional Requirements

FR1: Allow objects to receive their dependencies from an external source rather than creating them internally

FR2: Support constructor injection, setter injection, and interface injection

FR3: Manage lifecycle of dependencies (singleton, transient, scoped)

FR4: Provide a way to register and resolve dependencies dynamically

FR5: Support hierarchical containers for scoped dependencies

FR6: Enable easy testing by allowing mock dependencies to be injected

FR7: Handle circular dependencies gracefully with clear error reporting

Non-Functional Requirements

NFR1: Should be lightweight with minimal performance overhead

NFR2: Support up to 10,000 dependency registrations efficiently

NFR3: Resolve dependencies with p99 latency under 5ms

NFR4: Ensure thread safety for concurrent dependency resolution

NFR5: Provide 99.9% uptime for dependency resolution in production

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Dependency container/registry

Dependency resolver

Lifecycle manager

Configuration API for registration

Error handling module

Scope/hierarchy manager

Design Patterns

Service Locator pattern

Factory pattern

Singleton pattern

Proxy pattern for lazy loading

Builder pattern for configuration

Reference Architecture

 +---------------------+       +---------------------+       +---------------------+
 | Dependency Container|<----->| Lifecycle Manager    |<----->| Dependency Resolver  |
 +---------------------+       +---------------------+       +---------------------+
           ^                             ^                             ^
           |                             |                             |
 +---------------------+       +---------------------+       +---------------------+
 | Registration API     |       | Scope Manager       |       | Error Handler       |
 +---------------------+       +---------------------+       +---------------------+

Components

Dependency Container

In-memory registry

Stores mappings of interfaces to concrete implementations and manages registrations

Dependency Resolver

Recursive resolution algorithm

Resolves requested dependencies by constructing object graphs and injecting dependencies

Lifecycle Manager

Singleton, transient, scoped lifecycle handlers

Manages object lifetimes according to registration policies

Registration API

Fluent interface or configuration DSL

Allows users to register dependencies and specify lifecycles and injection types

Scope Manager

Hierarchical container support

Supports scoped lifetimes and nested containers for isolated dependency graphs

Error Handler

Exception and logging system

Detects circular dependencies and misconfigurations, providing clear error messages

Request Flow

1. User registers dependencies via Registration API specifying interface, implementation, and lifecycle

2. Dependency Container stores registration details

3. When a dependency is requested, Dependency Resolver checks Lifecycle Manager for existing instances

4. If no instance exists, Resolver recursively resolves all dependencies required by the implementation

5. Lifecycle Manager creates or retrieves instance according to lifecycle policy

6. Scope Manager ensures scoped dependencies are isolated per scope

7. If circular dependency detected, Error Handler raises descriptive error

8. Resolved instance returned to the requester

Database Schema

Not applicable - system uses in-memory data structures for registrations and resolutions

Scaling Discussion

Bottlenecks

Large number of dependency registrations causing slow lookup

Deep or complex dependency graphs increasing resolution time

Circular dependencies causing resolution failures

Concurrent access causing race conditions or inconsistent state

Memory overhead from storing many singleton instances

Solutions

Use efficient hash maps or tries for fast registration lookup

Implement caching of resolved dependency graphs to speed repeated resolutions

Detect circular dependencies early during registration or resolution with graph algorithms

Use locks or atomic operations to ensure thread safety during registration and resolution

Provide options to unload or dispose singleton instances when no longer needed

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing

Explain different injection types and lifecycle management

Describe how dependencies are registered and resolved

Discuss handling of circular dependencies and error reporting

Highlight thread safety and performance considerations

Show awareness of scaling challenges and mitigation strategies

Practice

1. What is the main purpose of a dependency injection framework?

easy

A. To store data permanently on disk

B. To automatically provide parts (dependencies) to your code

C. To make your code run faster by compiling it

D. To write all code manually without any helpers

Solution

1. Step 1: Understand what dependency injection means

   Dependency injection means giving the parts your code needs automatically instead of creating them inside the code.

2. Step 2: Identify the role of the framework

   A dependency injection framework helps by managing and providing these parts for you, making your code easier to change and test.

3. Final Answer:

   To automatically provide parts (dependencies) to your code -> Option B

4. Quick Check:

   Dependency injection = automatic parts supply [OK]

Hint: Think: Who gives parts to your code? The injector does! [OK]

Common Mistakes:

• Confusing dependency injection with data storage
• Thinking it speeds up code execution directly
• Believing it replaces manual coding completely

2. Which of the following is the correct way to register a service in a dependency injection framework?

easy

A. injector.register(ServiceClass)

B. ServiceClass.inject()

C. register.injector(ServiceClass)

D. ServiceClass.register()

Solution

1. Step 1: Recall the registration syntax

   In most dependency injection frameworks, you register a service by calling a method on the injector object and passing the service class.

2. Step 2: Match the correct syntax

   The correct syntax is injector.register(ServiceClass), which tells the injector to manage that service.

3. Final Answer:

   injector.register(ServiceClass) -> Option A

4. Quick Check:

   Register service = injector.register() [OK]

Hint: Register services by calling register on the injector [OK]

Common Mistakes:

• Calling register on the service class instead of injector
• Mixing method order or names
• Using non-existent methods like inject() on service

3. Given the code below, what will serviceA.getName() output?

class ServiceA {
  getName() { return 'Service A'; }
}

injector.register(ServiceA);
const serviceA = injector.get(ServiceA);
console.log(serviceA.getName());

medium

A. null

B. undefined

C. Error: Service not found

D. Service A

Solution

1. Step 1: Understand registration and retrieval

   The code registers ServiceA with the injector, then asks the injector to give an instance of ServiceA.

2. Step 2: Check the method call on the instance

   The instance has a method getName() that returns the string 'Service A'. So calling serviceA.getName() returns 'Service A'.

3. Final Answer:

   Service A -> Option D

4. Quick Check:

   Registered service returns its name [OK]

Hint: Registered services return their methods normally [OK]

Common Mistakes:

• Assuming injector.get returns undefined or null
• Forgetting to register before getting
• Expecting an error without registration

4. Identify the error in the following code snippet using a dependency injection framework:

class ServiceB {}

const serviceB = injector.get(ServiceB);
injector.register(ServiceB);

medium

A. ServiceB is registered after trying to get it

B. ServiceB class is missing a constructor

C. injector.get should be injector.fetch

D. injector.register should be called twice

Solution

1. Step 1: Check the order of registration and retrieval

   The code tries to get ServiceB from the injector before registering it, which causes an error because the injector doesn't know about ServiceB yet.

2. Step 2: Confirm correct usage order

   Services must be registered before they can be retrieved from the injector.

3. Final Answer:

   ServiceB is registered after trying to get it -> Option A

4. Quick Check:

   Register before get = correct order [OK]

Hint: Always register before getting a service [OK]

Common Mistakes:

• Trying to get service before registration
• Confusing method names like get vs fetch
• Thinking constructor is required for registration

5. You want to inject a Logger service into a UserService using a dependency injection framework. Which approach correctly applies dependency injection to make UserService easier to test?

class Logger {
  log(msg) { console.log(msg); }
}

class UserService {
  constructor(logger) {
    this.logger = logger;
  }
  createUser(name) {
    this.logger.log(`User ${name} created`);
  }
}

injector.register(Logger);
injector.register(UserService);

How should you get UserService with Logger injected?

hard

A. const userService = injector.get(Logger);

B. const userService = new UserService(new Logger());

C. const userService = injector.get(UserService);

D. const userService = UserService();

Solution

1. Step 1: Understand constructor injection

   UserService expects a Logger instance in its constructor. The injector knows how to create Logger and UserService because both are registered.

2. Step 2: Use injector to get UserService with dependencies

   Calling injector.get(UserService) lets the injector create UserService and automatically provide Logger to it.

3. Final Answer:

   const userService = injector.get(UserService); -> Option C

4. Quick Check:

   Injector provides dependencies via constructor [OK]

Hint: Get the service from injector to auto-inject dependencies [OK]

Common Mistakes:

• Manually creating dependencies instead of using injector
• Getting Logger instead of UserService
• Calling UserService without new keyword