Fix the design · Incident triage

Cart God Method: The 400-Line Service That Does Everything

A single addToCart() method keeps growing as features land, mixing validation, pricing, persistence, events, and analytics — more than one reason to change.

In a low-level design interview, InterviewCrafted opens addToCart(), scrolls through a very long method, and asks which design principle is broken.

We need your help. Identify which design principle this breaks and which jobs are mixed together, then fix the path from “add item” → “cart saved” so each piece has one reason to change and a new feature does not land in the same 400-line method.

Problem

Fix the team’s existing addToCart path — it already validates stock, prices the line, saves the cart, emits events, and records analytics in one method.

Incident summary

  • addToCart() has grown past four hundred lines and mixes several jobs in one place.
  • A pricing-rule change and a persistence change both land in the same method.
  • The method has more than one reason to change — that breaks single responsibility.
  • The team keeps saying they will split later while new features continue to land in the same place.

Assumptions made by the team

  • One large method is simpler to follow than several small classes.
  • There is no time to split the method before launch.
  • A method can have many reasons to change as long as the happy path still works.
  • Extracting classes later will be easy once the feature set settles.

Impacted services

  • CartService.addToCart (critical) — Six responsibilities in one method.
  • Pricing changes (degraded) — A promo rule change sits in the same method as save and events.
  • Gift wrap next month (degraded) — A new feature has nowhere to land except another block in addToCart.
  • Persistence (degraded) — Save logic cannot change without opening the same method as pricing.

Triage questions

  1. This one method seems to do a lot. What different jobs do you see mixed in here?
  2. If we change how prices work next week, which piece would you pull out first so we don’t also have to edit the save-to-database code?
  3. Next month we want gift wrapping at checkout. If we keep everything in addToCart, where does the new gift-wrap code go? If we break this into smaller pieces, where should that new code live instead?
  4. Is it ever OK to leave this as one long method? What goes wrong if we break it into lots of tiny classes before we really need to?

← All design challenges

Loading scenario…