Command pattern in LLD - System Design Exercise

Design: Command Pattern Implementation

Design the core command pattern structure including command interface, concrete commands, invoker, and receiver. Out of scope: UI integration and persistence of command history.

Functional Requirements

FR1: Allow encapsulation of requests as objects

FR2: Support undo and redo operations

FR3: Enable queuing and logging of commands

FR4: Decouple the object that invokes the operation from the one that knows how to perform it

Non-Functional Requirements

NFR1: Must support multiple command types with different parameters

NFR2: Commands should be executed asynchronously if needed

NFR3: Undo/redo operations should be efficient

NFR4: System should be extensible to add new commands without modifying existing code

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Command interface or abstract class

Concrete command classes implementing the interface

Invoker that calls commands

Receiver that performs the actual work

Command history stack for undo/redo

Design Patterns

Command pattern

Memento pattern for undo/redo state

Queue or buffer for asynchronous command execution

Composite pattern if commands can be grouped

Reference Architecture

Client
  |
  v
Invoker ---> Command Interface <--- Concrete Commands ---> Receiver
  |
  v
Command History (Stack for Undo/Redo)

Components

Command Interface

Abstract class or interface

Defines execute(), undo() methods for commands

Concrete Commands

Classes implementing Command Interface

Encapsulate specific actions and parameters

Invoker

Class

Calls execute() on commands and manages command history

Receiver

Class

Performs the actual operations requested by commands

Command History

Stack data structure

Stores executed commands for undo/redo

Request Flow

1. Client creates a Concrete Command with a Receiver and parameters

2. Client passes the command to the Invoker

3. Invoker calls execute() on the command

4. Command calls appropriate method(s) on the Receiver to perform action

5. Invoker stores the command in Command History stack

6. For undo, Invoker calls undo() on the last command from history

7. For redo, Invoker calls execute() again on the undone command

Database Schema

Not applicable - this is an in-memory design pattern implementation without persistent storage.

Scaling Discussion

Bottlenecks

Large number of commands causing memory pressure in history stack

Complex undo/redo logic for commands with side effects

Synchronous execution blocking invoker if commands take long

Difficulty adding new command types if interface is not flexible

Solutions

Limit history size or use persistent storage for command logs

Use Memento pattern to capture state snapshots for undo

Implement asynchronous command execution with queues and worker threads

Design command interface with extensibility in mind and use polymorphism

Interview Tips

Time: 10 minutes to clarify requirements and scope, 20 minutes to design components and data flow, 15 minutes to discuss scaling and trade-offs

Explain how command pattern decouples invoker and receiver

Describe how undo/redo is supported via command history

Discuss extensibility for adding new commands

Mention asynchronous execution for scalability

Highlight real-world use cases like GUI actions, transaction management