Flyweight pattern in LLD - System Design Exercise

Design: Flyweight Pattern Implementation

Design the Flyweight pattern structure and usage for a system that needs many similar objects with shared state. Out of scope: specific application domain details or UI integration.

Functional Requirements

FR1: Support creation of many similar objects efficiently

FR2: Share common intrinsic state among objects to save memory

FR3: Allow extrinsic state to be supplied externally when needed

FR4: Provide a way to manage and reuse shared objects

FR5: Ensure thread-safe access to shared objects if used concurrently

Non-Functional Requirements

NFR1: Must reduce memory usage significantly compared to naive object creation

NFR2: Should not compromise performance when accessing shared objects

NFR3: Design should be simple to integrate into existing systems

NFR4: Support up to 1 million objects with limited memory overhead

NFR5: Latency for object retrieval should be under 5ms

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Flyweight interface defining shared behavior

Concrete Flyweight objects holding intrinsic state

Flyweight Factory to manage and reuse flyweight instances

Client code supplying extrinsic state when using flyweights

Design Patterns

Flyweight pattern for memory optimization

Factory pattern for object creation and reuse

Caching strategies for efficient retrieval

Thread-safe singleton or pool for flyweight factory

Reference Architecture

Client
  |
  v
Flyweight Factory <----> Shared Flyweight Objects
  |
  v
Extrinsic State supplied by Client

Legend:
- Client requests flyweight from Factory
- Factory returns shared flyweight object
- Client uses flyweight with extrinsic state

Components

Flyweight Interface

Abstract class or interface in chosen language

Defines methods that flyweight objects must implement

Concrete Flyweight

Class implementing Flyweight Interface

Holds intrinsic (shared) state and implements behavior

Flyweight Factory

Singleton or static class

Creates and manages shared flyweight instances, returns existing ones if available

Client

Any application code

Requests flyweights from factory and supplies extrinsic state when using them

Request Flow

1. Client requests a flyweight object from the Flyweight Factory with a key representing intrinsic state

2. Factory checks if a flyweight with that intrinsic state exists

3. If exists, Factory returns the existing flyweight object

4. If not, Factory creates a new Concrete Flyweight with intrinsic state and stores it

5. Client receives the flyweight object

6. Client uses the flyweight object by passing extrinsic state as needed for operations

Database Schema

Not applicable as Flyweight pattern is a design pattern for in-memory object sharing, no persistent storage schema required.

Scaling Discussion

Bottlenecks

Factory lookup time increases with number of flyweights

Memory overhead if intrinsic state is not properly shared

Thread contention if factory is accessed concurrently without synchronization

Garbage collection pressure if many flyweights are created and discarded

Solutions

Use efficient data structures like hash maps for factory lookup

Carefully identify and separate intrinsic vs extrinsic state to maximize sharing

Implement thread-safe factory using locks or concurrent data structures

Use weak references or caching policies to allow unused flyweights to be garbage collected

Interview Tips

Time: Spend 10 minutes explaining the problem and pattern concept, 15 minutes designing the components and data flow, 10 minutes discussing scaling and trade-offs, 10 minutes answering questions.

Explain difference between intrinsic and extrinsic state clearly

Describe how factory manages shared objects and avoids duplication

Discuss thread safety and memory optimization benefits

Mention real-world examples like text editors sharing character glyphs

Highlight trade-offs between complexity and memory savings