Bird
Raised Fist0
LLDsystem_design~10 mins

Anti-patterns to avoid in LLD - Interactive Code Practice

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
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to avoid the {{BLANK_1}} anti-pattern in system design.

LLD
def handle_request(request):
    # Avoid [1] by not tightly coupling components
    pass
Drag options to blanks, or click blank then click option'
Ascalability
Bspaghetti_code
Cmodularity
Dperformance
Attempts:
3 left
💡 Hint
Common Mistakes
Choosing 'performance' instead of the messy code pattern.
2fill in blank
medium

Complete the code to prevent the {{BLANK_1}} anti-pattern by using proper data storage.

LLD
def save_data(data):
    # Avoid [1] by not storing all data in one place
    pass
Drag options to blanks, or click blank then click option'
Acaching
Bload_balancing
Csingle_point_of_failure
Dredundancy
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing with 'load_balancing' which is a solution, not an anti-pattern.
3fill in blank
hard

Fix the error in the code that causes the {{BLANK_1}} anti-pattern by separating concerns.

LLD
class UserManager:
    def __init__(self):
        self.db = Database()
    def process(self, data):
        # This causes [1] by mixing logic and data access
        self.db.save(data)
        self.send_email(data)
Drag options to blanks, or click blank then click option'
Agod_object
Btight_coupling
Ccircular_dependency
Drace_condition
Attempts:
3 left
💡 Hint
Common Mistakes
Choosing 'tight_coupling' which is related but not the main issue here.
4fill in blank
hard

Fill both blanks to avoid the {{BLANK_1}} and {{BLANK_2}} anti-patterns in system design.

LLD
def process_request(req):
    # Avoid [1] by not blocking main thread
    # Avoid [2] by not duplicating code
    pass
Drag options to blanks, or click blank then click option'
Ablocking_io
Bcode_duplication
Cmemory_leak
Dtight_coupling
Attempts:
3 left
💡 Hint
Common Mistakes
Mixing up 'memory_leak' with blocking issues.
5fill in blank
hard

Fill all three blanks to fix the {{BLANK_1}}, {{BLANK_2}}, and {{BLANK_3}} anti-patterns in this code snippet.

LLD
def handle_data(data):
    # Avoid [1] by not sharing mutable state
    # Avoid [2] by not ignoring errors
    # Avoid [3] by not overloading one service
    pass
Drag options to blanks, or click blank then click option'
Ashared_mutable_state
Bsilent_failures
Cservice_monolith
Dover_provisioning
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing 'over_provisioning' with 'service_monolith'.

Practice

(1/5)
1. Which of the following best describes the God Object anti-pattern in system design?
easy
A. Separating data storage and business logic into different layers.
B. A system design where components are loosely connected and communicate via events.
C. A single component that handles too many responsibilities, making the system hard to maintain.
D. Using multiple small services to handle different tasks independently.

Solution

  1. Step 1: Understand the God Object concept and compare options

    The God Object anti-pattern occurs when one component or class takes on too many responsibilities, leading to complex, hard-to-maintain code. A single component that handles too many responsibilities, making the system hard to maintain. matches this description exactly, while others describe good design practices.
  2. Final Answer:

    A single component that handles too many responsibilities, making the system hard to maintain. -> Option C
  3. Quick Check:

    God Object = Single overloaded component [OK]
Hint: God Object means one part does too much [OK]
Common Mistakes:
  • Confusing God Object with microservices
  • Thinking God Object is a good modular design
  • Mixing God Object with event-driven architecture
2. Which of the following is an example of a hardcoding anti-pattern in system design?
easy
A. Storing configuration values directly inside the source code.
B. Using environment variables for configuration.
C. Separating configuration into external files.
D. Using feature flags to toggle functionality.

Solution

  1. Step 1: Identify what hardcoding means and match options

    Hardcoding means embedding fixed values directly in the code, making changes difficult and error-prone. Storing configuration values directly inside the source code. shows storing config inside code, which is hardcoding. Others are best practices.
  2. Final Answer:

    Storing configuration values directly inside the source code. -> Option A
  3. Quick Check:

    Hardcoding = fixed values in code [OK]
Hint: Hardcoding means fixed values inside code [OK]
Common Mistakes:
  • Confusing hardcoding with using environment variables
  • Thinking external config files are hardcoding
  • Mixing feature flags with hardcoding
3. Consider a system where all modules directly access a single shared database without any abstraction layer. What is the main anti-pattern here?
medium
A. Tight Coupling
B. God Object
C. Spaghetti Architecture
D. Event-Driven Design

Solution

  1. Step 1: Analyze direct database access and identify the anti-pattern

    When modules directly access the database without abstraction, they become tightly coupled to the database schema. Tight Coupling means components depend heavily on each other, reducing flexibility and increasing maintenance difficulty.
  2. Final Answer:

    Tight Coupling -> Option A
  3. Quick Check:

    Direct DB access = Tight Coupling [OK]
Hint: Direct DB access causes tight coupling [OK]
Common Mistakes:
  • Confusing tight coupling with God Object
  • Thinking event-driven design fits here
  • Mixing spaghetti architecture with tight coupling
4. You find a system where many components are tightly interconnected with complex dependencies, making it hard to change one without breaking others. What anti-pattern is this, and how can you fix it?
medium
A. God Object; merge all components into one big class.
B. Spaghetti Architecture; refactor to modular design with clear interfaces.
C. Hardcoding; move all values into source code.
D. Tight Coupling; remove all interfaces and use direct calls.

Solution

  1. Step 1: Identify the anti-pattern from description and determine the fix

    Complex interdependencies causing fragility is typical of Spaghetti Architecture. Refactoring to modular design with clear interfaces reduces dependencies and improves maintainability.
  2. Final Answer:

    Spaghetti Architecture; refactor to modular design with clear interfaces. -> Option B
  3. Quick Check:

    Spaghetti Architecture = tangled dependencies [OK]
Hint: Tangled dependencies = spaghetti; modularize [OK]
Common Mistakes:
  • Thinking God Object means merging components
  • Confusing hardcoding with architecture issues
  • Believing removing interfaces reduces coupling
5. A startup built a monolithic system with many hardcoded values and a God Object managing most logic. They want to scale and maintain it easily. What is the best approach to fix these anti-patterns?
hard
A. Ignore scalability and focus only on adding new features.
B. Keep the monolith but add more hardcoded values for speed.
C. Merge all logic into one bigger God Object for simplicity.
D. Refactor into microservices, externalize configuration, and split responsibilities into smaller components.

Solution

  1. Step 1: Identify problems in current system and choose best solution to fix anti-patterns

    Monolith with hardcoded values and God Object causes poor scalability and maintainability. Refactoring into microservices splits responsibilities, externalizing config removes hardcoding, improving scalability and maintainability.
  2. Final Answer:

    Refactor into microservices, externalize configuration, and split responsibilities into smaller components. -> Option D
  3. Quick Check:

    Microservices + external config fix anti-patterns [OK]
Hint: Split monolith, externalize config, avoid God Object [OK]
Common Mistakes:
  • Thinking bigger God Object improves simplicity
  • Adding more hardcoding for speed
  • Ignoring scalability needs