Bird
Raised Fist0
LLDsystem_design~25 mins

Iterator pattern in LLD - System Design Exercise

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Iterator Pattern Implementation
Design the iterator pattern focusing on the interface and interaction with collections. Implementation details of collections themselves are out of scope except for demonstration.
Functional Requirements
FR1: Provide a way to access elements of a collection sequentially without exposing its underlying representation
FR2: Support multiple types of collections (e.g., lists, trees, graphs)
FR3: Allow multiple iterators to traverse the same collection independently
FR4: Support forward traversal at minimum; optional support for backward traversal
FR5: Ensure the iterator interface is simple and consistent across collection types
Non-Functional Requirements
NFR1: Iterator operations should have O(1) time complexity where possible
NFR2: Memory overhead should be minimal and proportional to the number of active iterators
NFR3: The design should be extensible to support new collection types without modifying existing code
NFR4: Thread safety is not required in the initial design
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
Key Components
Iterator interface defining traversal methods
Concrete iterator implementations for each collection type
Aggregate interface representing collections that can create iterators
Concrete aggregate implementations (e.g., List, Tree)
Client code that uses iterators to traverse collections
Design Patterns
Iterator pattern for traversal abstraction
Composite pattern if collections are hierarchical (like trees)
Factory method pattern for creating iterators
Decorator pattern if adding extra behavior to iterators
Reference Architecture
Client
  |
  v
Aggregate Interface <---- Concrete Aggregates (List, Tree)
  |
  v
Iterator Interface <---- Concrete Iterators (ListIterator, TreeIterator)

Components
Iterator Interface
Abstract Interface
Defines methods like next(), hasNext() to traverse elements
Concrete Iterator
Class implementing Iterator Interface
Implements traversal logic specific to a collection type
Aggregate Interface
Abstract Interface
Defines method to create an iterator for the collection
Concrete Aggregate
Class implementing Aggregate Interface
Represents a collection and returns its iterator
Client
Application code
Uses iterator interface to traverse collections without knowing their structure
Request Flow
1. Client requests an iterator from a collection (Aggregate)
2. Collection returns a Concrete Iterator instance
3. Client uses iterator's hasNext() and next() methods to access elements sequentially
4. Iterator internally manages traversal state without exposing collection structure
5. Client completes traversal or stops early without affecting collection
Database Schema
Not applicable for Iterator pattern as it is a behavioral design pattern focusing on object interaction rather than data storage.
Scaling Discussion
Bottlenecks
Multiple iterators on large collections may increase memory usage
Complex collections like trees may have more complex iterator logic affecting performance
If collections are modified during iteration, iterator consistency can break
Supporting backward traversal or random access may complicate iterator design
Solutions
Use lightweight iterator objects and share immutable state where possible
Optimize traversal algorithms for complex collections
Implement fail-fast or fail-safe iterators to handle concurrent modifications
Design separate iterator interfaces for different traversal capabilities (forward, backward)
Interview Tips
Time: Spend 10 minutes explaining the problem and requirements, 15 minutes designing interfaces and classes, 10 minutes discussing scaling and extensions, and 10 minutes answering questions.
Explain the need to separate traversal from collection structure
Describe how the iterator interface provides a uniform way to access elements
Show how multiple iterators can work independently on the same collection
Discuss trade-offs between simplicity and supporting advanced traversal features
Mention how the pattern improves code maintainability and extensibility

Practice

(1/5)
1.

What is the main purpose of the Iterator pattern in system design?

easy
A. To manage user authentication and authorization
B. To store data in a database efficiently
C. To create multiple copies of an object
D. To provide a way to access elements of a collection sequentially without exposing its underlying structure

Solution

  1. Step 1: Understand the role of Iterator pattern

    The Iterator pattern is designed to provide a way to access elements of a collection one by one without revealing the internal structure of the collection.
  2. Step 2: Compare with other options

    Options B, C, and D describe unrelated design patterns or system functions such as data storage, object cloning, and security management.
  3. Final Answer:

    To provide a way to access elements of a collection sequentially without exposing its underlying structure -> Option D
  4. Quick Check:

    Iterator pattern = Access collection without exposing structure [OK]
Hint: Iterator = access elements without showing internal details [OK]
Common Mistakes:
  • Confusing Iterator with data storage or cloning patterns
  • Thinking Iterator manages security or authentication
  • Assuming Iterator modifies the collection
2.

Which of the following is the correct method signature for the next() method in an iterator interface?

easy
A. def next() -> void
B. def next(self, index) -> Element
C. def next(self) -> Element
D. def next(self, element) -> bool

Solution

  1. Step 1: Recall the standard iterator method signature

    The next() method typically takes no parameters except the implicit self and returns the next element in the collection.
  2. Step 2: Analyze each option

    def next(self) -> Element matches the standard signature: it takes self and returns an element. Options B and D incorrectly add parameters, and C returns void which is incorrect.
  3. Final Answer:

    def next(self) -> Element -> Option C
  4. Quick Check:

    next() takes no args, returns element [OK]
Hint: next() returns next element, no extra parameters [OK]
Common Mistakes:
  • Adding parameters to next() method
  • Returning void instead of element
  • Confusing next() with hasNext() method
3.

Consider the following Python code implementing a simple iterator:

class MyIterator:
    def __init__(self, data):
        self.data = data
        self.index = 0
    def __iter__(self):
        return self
    def __next__(self):
        if self.index < len(self.data):
            result = self.data[self.index]
            self.index += 1
            return result
        else:
            raise StopIteration

it = MyIterator([10, 20, 30])
print(next(it))
print(next(it))

What will be the output?

medium
A. 20\n30
B. 10\n20
C. 10\n30
D. Error at runtime

Solution

  1. Step 1: Trace the iterator's next calls

    First call to next(it) returns data[0] = 10 and increments index to 1. Second call returns data[1] = 20 and increments index to 2.
  2. Step 2: Confirm no errors occur

    Since index is less than length during both calls, no StopIteration is raised.
  3. Final Answer:

    10 20 -> Option B
  4. Quick Check:

    First two elements printed: 10 and 20 [OK]
Hint: next() returns elements in order, increments index [OK]
Common Mistakes:
  • Assuming next() skips elements
  • Expecting error before StopIteration
  • Mixing up index increments
4.

Given this iterator implementation in Python, identify the bug:

class BuggyIterator:
    def __init__(self, data):
        self.data = data
        self.index = 0
    def __iter__(self):
        return self
    def __next__(self):
        if self.index <= len(self.data):
            result = self.data[self.index]
            self.index += 1
            return result
        else:
            raise StopIteration

What is the cause of the error when iterating?

medium
A. IndexError due to accessing out-of-range element
B. StopIteration raised too early
C. Infinite loop because index never increments
D. Syntax error in method definitions

Solution

  1. Step 1: Analyze the condition in __next__

    The condition uses <= len(self.data), which allows index to equal length, causing out-of-range access.
  2. Step 2: Understand the error caused

    Accessing self.data[self.index] when index == len(self.data) causes IndexError because list indices go from 0 to len-1.
  3. Final Answer:

    IndexError due to accessing out-of-range element -> Option A
  4. Quick Check:

    Condition allows index == length causing IndexError [OK]
Hint: Use < not <= to avoid out-of-range errors [OK]
Common Mistakes:
  • Using <= instead of < in boundary check
  • Assuming StopIteration triggers before error
  • Ignoring index increment effects
5.

You need to design an iterator for a complex data structure that contains nested lists of integers. Which approach best follows the Iterator pattern principles to allow clients to iterate over all integers seamlessly?

  1. Flatten the nested lists into a single list before iteration.
  2. Implement a recursive iterator that yields integers from nested lists on demand.
  3. Expose the internal nested list structure and let clients handle iteration.
  4. Provide separate iterators for each nested list and require clients to manage them.
hard
A. Implement a recursive iterator that yields integers from nested lists on demand
B. Flatten the nested lists into a single list before iteration
C. Expose the internal nested list structure and let clients handle iteration
D. Provide separate iterators for each nested list and require clients to manage them

Solution

  1. Step 1: Understand Iterator pattern goal

    The pattern aims to hide internal structure and provide a simple way to access elements sequentially.
  2. Step 2: Evaluate each approach

    Flatten the nested lists into a single list before iteration flattens data upfront, which may be inefficient and breaks lazy access. Implement a recursive iterator that yields integers from nested lists on demand uses a recursive iterator to yield elements on demand, hiding complexity and supporting lazy iteration. Options C and D expose internal structure or complexity to clients, violating encapsulation.
  3. Final Answer:

    Implement a recursive iterator that yields integers from nested lists on demand -> Option A
  4. Quick Check:

    Recursive iterator hides structure, yields elements lazily [OK]
Hint: Use recursive iterator to hide nested structure [OK]
Common Mistakes:
  • Flattening data upfront losing lazy iteration benefits
  • Exposing internal structure breaking encapsulation
  • Forcing clients to manage multiple iterators