Problem Solving and DSA
Problem → Constraints → Pattern → Algorithm. The algorithm is the last step, and the step people start from. The constraints — how much data, how often it changes, what "fast enough" means — are what pick the pattern, and the pattern is what picks the algorithm.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
A piece of the store needs an algorithm and you do not know which. How does the problem-solving loop get you from the requirement to the right one, and what does it hand off to the DSA domain?
"Search products by name" is on the board. You know a dozen data structures and you can feel them all wanting to be used — a trie, a hash map, a sorted array with binary search, a full-text index. You do not know which one the store needs, and you suspect the honest answer is "it depends" without knowing on what.
Pick the most sophisticated structure that fits the word "search". A trie handles prefixes; that is what search-as-you-type does; build a trie. It is a real solution to a real problem, and implementing it produces a satisfying afternoon.
The trie is a solution to prefix matching over a static set in memory. Nobody has said the matching is by prefix, that the catalog fits in memory, or that it is static — the admin edits products daily. Three constraints, none checked, and the structure was chosen against all of them.
- The trie is a solution to prefix matching over a static set in memory. Nobody has said the matching is by prefix, that the catalog fits in memory, or that it is static — the admin edits products daily. Three constraints, none checked, and the structure was chosen against all of them.
- The afternoon produced a data structure and no answer to "does the store need this?" A catalog of a few hundred products would be searched fine by a linear scan; the trie's advantage exists only at a scale nobody measured.
- "Fast enough" was never defined, so the trie cannot be shown to be fast enough or to be needed. Without a target, every structure is either over- or under-engineered and there is no way to tell which.
- When the requirement turns out to be "contains, case-insensitive, with typos tolerated", the trie is wrong and the afternoon is gone. The pattern was chosen before the problem was stated.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Run the chain in order: Problem → Constraints → Pattern → Algorithm. The problem is what the user needs, in their words. The constraints are the numbers and the shape — how many items, how often they change, how often they are queried, what latency is acceptable, what memory is available. The pattern is the class of approach the constraints admit — scan, index, hash, tree, sort-then-search, sliding window, graph traversal. The algorithm is the concrete choice within the pattern, and it is the only step the DSA domain teaches.
- Make the constraints numbers, even rough ones, before naming a pattern. "How many products?" and "how often does the catalog change?" and "what is the slowest acceptable search?" decide the pattern; without them, every pattern is plausible and the choice is taste (Time, Users, Data).
- Name the pattern before the algorithm, and name the simplest pattern the constraints allow. A scan is a pattern. If a scan meets the constraints, the algorithm question is over; if it does not, the way it fails says which pattern comes next (The Simplest Thing That Could Work).
- Hand off at the algorithm. Once the pattern is "prefix lookup over an in-memory set that changes rarely", the finder at /finder and the DSA lessons choose between a trie and a sorted array; that is their job, and it is short once the pattern is fixed.
The chain, with what each step produces
The pipeline is four steps and the DSA domain owns only the last. Each step produces something the next one needs, and each is skipped in a characteristic way — usually by starting at the end.
- 1Problem
What the user needs, in their words — and which of the three meanings of "search" they mean.
fails by Taking "search" as self-explanatory.
- 2Constraints
Count, change rate, query rate, latency budget, memory — rough numbers, marked as guesses where they are.
fails by Numbers invented to justify the structure already wanted.
- 3Pattern
The simplest class of approach the constraints admit: scan, index, hash, tree, window, traversal.
fails by Naming an algorithm and calling it a pattern.
- 4Algorithm
The concrete choice within the pattern — the DSA domain's job, via the finder at /finder.
fails by Re-deriving it instead of reading the comparison.
The scan is a pattern, and it is the one to try first. If it meets the constraints the chain ends there; its failure mode is what selects the next pattern.
"Search" asked three ways
The Problem step is where the chain is most often skipped, because "search" sounds like a problem statement. It is three problem statements, and each selects a different pattern. The ladder shows the same feature sharpened until the pattern is decidable.
why The best form contains all four constraints and the meaning of "part", so the pattern falls out — in-memory, rebuilt on change, substring — and the scan can be tested against a stated budget. The vague form admits every structure in the book; the better form still does not say whether "part" is a prefix, which is the difference between a trie and a scan.
Which pattern the constraints pick
The decision below is the Pattern step for the store's search, with the constraint that selects each option and what it costs. The criteria are the lesson; the finder chooses within the winning row.
What do the constraints say the search should be built on?
when Thousands of items or fewer; substring or prefix; a measured scan fits the latency budget.
cost Linear per query; must be rebuilt or updated when the catalog changes; no ranking beyond order of match.
when Prefix match only; the set is large enough that a scan misses the budget; changes are rare enough that rebuilding is acceptable.
cost Prefix only; a rebuild on every change, or an update path that has to be written and tested.
when Substring or fuzzy match over a set too large for memory, or typo tolerance and ranking are requirements, or the data changes constantly.
cost A component to operate and keep in sync with the catalog; the failure modes of that sync (External Systems Fail).
How to do it
Most important first.
- Write the problem as the user would say it: "I type part of a name and see matching products". Then ask whether "part" means prefix, substring, or approximately — three different patterns (Restating the Problem).
- Write four numbers: item count, change rate, query rate, acceptable latency. Guess where you must, and mark the guesses as assumptions to verify (The Assumption Register).
- Try the scan first, on real or realistic data, and measure. Most catalogs are small enough that the scan is the answer, and the measurement is what justifies anything more (Measure Before You Optimize in the performance domain says why).
- If the scan fails, say how — too slow per query, too slow to rebuild on change, too much memory — because each failure points to a different pattern.
- Only then open the finder with the pattern in hand, and compare algorithms within it on the constraints you wrote down.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Search products by name, run through the chain. Problem: a customer types part of a name and sees matching products as they type. Constraints: a few thousand products, edited by the admin a few times a day, queried on every keystroke, with results expected before the next keystroke. Pattern: the catalog fits in memory and changes rarely, so an in-memory structure rebuilt on change is admissible; the query is substring, case-insensitive. A scan over a few thousand lowercased names per keystroke is measured and is well within budget. Algorithm: a linear scan. The trie was never needed, and the chain says exactly what would change that — an order of magnitude more products, or a requirement for typo tolerance.
- The same chain on the chat app's "who is online". Problem: show which conversation members are online. Constraints: many users, presence changes every few seconds, queried on every conversation open. Pattern: a set with fast membership and fast update. Algorithm: a hash set keyed by user id, handed off to the DSA lessons on hashing. The chain took five minutes because the constraints were obvious; that is the chain working, not being skipped.
- The URL shortener's "most clicked links today". Problem: a top-N over a stream of click events. Constraints: many clicks, N small, "today" is a sliding window. Pattern: counting plus a bounded top-N — which is a heap, or a sliding-window count. The pattern names the algorithm family, and the DSA domain's heap and sliding-window lessons choose within it.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Four numbers exist for the problem — count, change rate, query rate, latency — before any structure is named.
- The pattern is named in words that are not an algorithm: "in-memory, rebuilt on change, substring match".
- The scan was tried and measured, and either it is the answer or its failure mode is written down.
- The handoff to the DSA domain is a comparison within one pattern, not a tour of every structure.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What does the user actually need — and does "search" mean prefix, substring or approximate?
- ?How many items, how often do they change, how often is it queried, and how slow is too slow?
- ?What is the simplest pattern those constraints allow, and has it been tried and measured?
- ?If the simple pattern fails, how does it fail — and which pattern does that failure point at?
What can go wrong
- The constraints are invented to justify the structure already wanted. "Millions of products" written down for a store with hundreds is the technology-first reflex with numbers (Technology-First Thinking).
- The scan is never tried because it is "obviously" too slow. Obviously is not a measurement; many search boxes on many stores are scans.
- The chain is run on problems that do not have an algorithm in them. Most of the store is CRUD; running Problem → Constraints → Pattern on "save the product" produces nothing.
- The handoff never happens. Having named the pattern, the engineer re-derives the trie from first principles instead of reading the lesson that already compares the options.
- Measuring the scan costs an hour that the trie enthusiast would have spent building. On a catalog that turns out to be huge, the hour was spent confirming what was obvious.
- Constraints written as guesses can be wrong, and a pattern chosen on a wrong guess has to be revisited. The alternative — no constraints — cannot be revisited because nothing was written.
- Handing off to the DSA domain means reading rather than deriving, which is faster and teaches less. The learning has to come from somewhere else.
- "So always use the simplest structure." Use the simplest structure the constraints allow, and write down the constraints so that when they change, the structure can. A store with a huge catalog and typo tolerance needs a real index, and the chain says so.
- "Constraints mean exact numbers." Rough numbers and their order of magnitude are enough to pick a pattern; the chain needs to know "thousands, not millions", not the precise count.
- "This replaces knowing the algorithms." It orders the knowing. You still need to recognise a heap when the pattern says top-N; the chain just stops you reaching for one before the pattern exists.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALProblem → Constraints → Pattern → Algorithm applies wherever an algorithm is being chosen; what varies by domain is which constraints dominate — latency for search, memory for embedded, change rate for anything editable.
- SCALE-SPECIFICBelow a few thousand items almost every pattern collapses to "scan it", and the chain is mainly a check that this is so. Above that, the pattern choice is real and the constraint numbers have to be measured rather than guessed.
- ILLUSTRATIVEThe few thousand products, the keystroke budget and the presence set are invented for the shape of the chain; a real store would measure its own numbers.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The DSA finder at /finder takes the pattern and the constraints and returns the candidates; arrive with the four numbers written down, not with a structure in mind.
- — The case study Case: Search Products by Name runs this chain end to end on the store.