The Technical Decision Atlas

One of the most underrated skills in technical work is not knowing how something works - it is knowing when to use it. Most education teaches tools in isolation. You learn dynamic programming in one chapter, greedy algorithms in another, neural networks somewhere else entirely. Rarely does anyone step back and draw the map that connects them.

This post is that map.

It is not a replacement for understanding the individual topics. It is the layer above them - a guide to the decision-making process: which family of tools applies to which kind of problem, what the tradeoffs are, and where the boundaries of each approach lie. Think of it as a field guide you can return to when you know what you are trying to solve but are not yet sure what to reach for.

Part 1: Algorithm Design

The first question to ask when you face a computational problem is structural: what kind of problem is this?

The key distinctions:

• Dynamic programming applies when a problem has overlapping subproblems and optimal substructure - meaning the optimal solution to the whole is built from optimal solutions to parts, and those parts recur. Classic sign: you find yourself computing the same subproblem multiple times.

• Greedy applies when you can prove that the locally optimal choice at each step leads to a globally optimal solution. This is often surprisingly hard to prove - and surprisingly easy to assume incorrectly. Always verify with a counterexample or an inductive proof.

• Branch and Bound / ILP is for when you need the exact optimal solution in a combinatorial space and cannot decompose it cleanly. Expensive but correct.

• Local search / metaheuristics (simulated annealing, genetic algorithms, tabu search) trade optimality guarantees for tractability. When the search space is too large for exact methods and approximate solutions are acceptable, these are your tools.

• Graph algorithms are a domain unto themselves. The choice of which to use depends almost entirely on what property of the graph you need: shortest paths, minimum spanning structure, maximum flow, connected components.

Part 2: Machine Learning

The machine learning decision is usually less about algorithm cleverness and more about the nature of your data and objective.

The key distinctions:

• Supervised vs. unsupervised vs. RL is the first fork. Supervised learning requires labeled examples. Unsupervised learning finds structure without labels. Reinforcement learning learns from interaction with an environment via a reward signal - it is neither supervised nor unsupervised.

• Interpretability vs. accuracy is a real tradeoff. Simpler models are more interpretable and often more robust on small datasets. Deep neural networks are more powerful but opaque. In high-stakes domains (medicine, law, finance), interpretability is often non-negotiable.

• Generative models (VAE, GAN, diffusion) are fundamentally different from discriminative models. Discriminative models learn the boundary between classes. Generative models learn the full data distribution. Use generative models when you need to create new data, not just classify existing data.

• Transfer learning collapses many of these decisions. If a pretrained model exists for your domain, fine-tuning it almost always beats training from scratch on limited data.

Part 3: Mathematical Foundations

Different mathematical tools illuminate different structures. Knowing which branch of mathematics is relevant to your problem is a skill that develops slowly but pays off substantially.

The key insight: these branches are not truly separate. Most hard problems require more than one. Gradient descent is calculus applied to linear algebra structures over a probabilistic objective. Graph algorithms use combinatorics for their correctness proofs. Bayesian inference uses linear algebra for its computations and information theory for its foundations. When a problem resists one mathematical lens, try another.

Part 4: Systems Design

Systems design decisions are almost always about what you are willing to sacrifice. The question is never “what do I want” - it is “what can I not afford to give up?”

The default you should internalize: most systems are read-heavy by a large margin - often 10:1 or 100:1 reads to writes. This means the default answer for “how do I make this fast” is almost always caching, not optimizing writes. Most performance problems are cache-miss problems in disguise.

When consistency actually matters: a bank cannot show you a stale balance when you are mid-transfer. A social media feed can be 30 seconds stale and no one notices. A stock trading system showing a price 200ms old can cost millions. The question is not whether to use eventual consistency in principle - it is whether your specific use case will break if two nodes disagree for 50ms. Most will not.

The failure mode nobody talks about: Byzantine fault tolerance (BFT) is rarely needed in internal systems where all nodes are under your control. Crash failures are common; nodes rarely lie. BFT matters in adversarial settings - blockchains, voting systems, anything where a participant has an incentive to cheat. Using BFT in a normal distributed system is engineering overkill that adds complexity for no benefit.

Part 5: Statistics and Probability

Probability and statistics are not the same thing, though they are deeply intertwined. Probability is the mathematical framework for reasoning about uncertainty before you see data - it asks “given a model of the world, what outcomes should I expect?” Statistics runs the inference in reverse - given outcomes I observed, what can I say about the model? Probability is forward; statistics is backward.

When you need probability theory:

Choosing a distribution is not a formality. The choice encodes an assumption about how the world generates data. Gaussian assumes symmetric noise around a mean - reasonable for measurement error, wrong for income distributions or event counts. Poisson assumes rare independent events in a fixed interval - right for server crashes per hour, wrong for user behavior that clusters. Exponential assumes memoryless waiting times - right for radioactive decay, wrong for anything where past duration changes future probability (human lifespans, machine failure after wear). Choosing the wrong distribution produces confident wrong answers.

The distributions worth knowing intuitively:

• Gaussian - sums of many independent small effects (Central Limit Theorem). Ubiquitous in nature, but overused.
• Poisson - count of rare independent events in a fixed window. Errors in code, mutations in DNA, cars at a toll booth.
• Exponential - time until first event in a Poisson process. Memoryless: if nothing has happened in 10 minutes, the next 10 minutes look the same.
• Beta - probability of a probability, bounded between 0 and 1. Used as a prior on proportions. An A/B test click rate is naturally modeled with Beta.
• Power law - rare but enormous events dominate. City sizes, word frequencies, wealth distributions, earthquake magnitudes. A Gaussian here catastrophically underestimates extreme events.

When you need statistics (inference from data):

The things that actually trip people up:

• P-hacking: if you test 20 hypotheses at p < 0.05, one will cross the threshold by pure chance. Decide what you are testing before you look at the data.
• Survivorship bias: if you only observe data from cases that made it through some filter, your inference is about the survivors, not the population. Studying successful startups tells you nothing about what makes startups succeed.
• Simpson’s paradox: a treatment can appear beneficial in aggregate while being harmful in every subgroup, if the subgroups were not equally represented. Always stratify before concluding.
• Effect size vs. significance: with enough data, a 0.001% difference in conversion rate is statistically significant. It is not worth acting on. Statistical significance measures whether an effect exists; effect size measures whether it matters.

Bayesian vs. frequentist in practice: use Bayesian when your data is sparse and your prior is meaningful - drug trials with historical data, recommendation systems with user history, anything where you would feel dishonest ignoring what you already know. Use frequentist when you have abundant data, need a standard reportable result, or your prior is genuinely uninformative. The philosophical debate matters much less than whether your prior is actually honest.

Part 6: Information Theory

Information theory answers a precise question: how much is actually communicated? It is the foundation of compression, cryptography, channel design, and surprisingly, machine learning.

Where information theory unexpectedly appears:

• In machine learning, cross-entropy loss is literally the information-theoretic measure of how well your model’s distribution matches the true distribution.
• In RL, policy entropy regularization (as in PPO) uses entropy to encourage exploration.
• In neuroscience, information theory measures how much a neuron’s firing pattern communicates about a stimulus.
• In compression, entropy sets a fundamental limit on how small any lossless encoding can be.

The Meta-Map: Hidden Identities Across Domains

The most interesting connections between these domains are not that “math supports algorithms” - that is obvious. The interesting connections are where two things that look different turn out to be the same object viewed from different angles.

When you minimize cross-entropy loss in a neural network, you are simultaneously: doing maximum likelihood estimation (statistics), minimizing KL divergence from the true distribution (information theory), applying gradient descent on a loss landscape (calculus), and running backpropagation to compute gradients efficiently (algorithms). These are not four separate things. They are one thing described in four languages.

The curse of dimensionality is a shared adversary that appears independently in algorithms, ML, and statistics. In algorithms, it makes naive nearest-neighbor search exponentially expensive. In ML, it means your training data becomes increasingly sparse as features grow - models need explicit regularization to avoid overfitting. In statistics, nonparametric density estimation requires exponentially more data as dimensions increase. It is not three different problems; it is one geometric fact with three faces.

MCMC is simultaneously a statistical technique, a randomized algorithm, and a core training method for Bayesian ML models. Which domain it “belongs to” depends entirely on who is using it and why.

Some patterns worth internalizing:

• When you see optimization: ask what you are actually optimizing for (statistics), whether the objective is convex (math), what the complexity of exact optimization is (algorithms), and whether approximate suffices (metaheuristics).
• When you see data: ask how much information it actually contains (information theory), whether there is enough to trust the inference (statistics), and what pattern can be learned efficiently (ML + algorithms).
• When you see scale: ask what the complexity class is (algorithms), whether the model degrades gracefully (ML), and whether the system can distribute the computation reliably (systems).
• When you see uncertainty: it is simultaneously a statistics question (quantify it), an information theory question (how much of it?), a systems question (how do you handle failures caused by it?), and an ML question (can the model express it?).

A Worked Example: Fraud Detection

To make this concrete, consider the problem of detecting fraudulent transactions in real time. Rather than just describing the solution, this section walks through the actual reasoning at each step - the questions asked, the options considered, and why each was chosen or rejected.

The problem

A transaction arrives. You have under 100ms to decide whether it is fraudulent before the payment times out. The input is: transaction amount, merchant category, location, timestamp, device fingerprint, and the user’s historical transaction patterns. The output is a single number: fraud probability. Fraud is rare - maybe 0.1% of transactions. The system must handle millions of transactions per day.

Analysis 1: What kind of ML problem is this?

Question asked: do we have labeled data? Yes - historical transactions are labeled fraud or not. So this is supervised learning, not unsupervised.

Question asked: are we predicting a category or a continuous value? A category (fraud / not fraud), so classification.

Question asked: is the data tabular or unstructured? Tabular - amounts, timestamps, merchant codes. Not images or text. This matters because neural networks dominate on unstructured data but tree-based models are competitive or better on tabular data.

Conclusion from ML map: supervised classification on tabular data → tree-based model family is the right starting point.

Analysis 2: Which classifier specifically?

Options on the table: logistic regression, decision tree, random forest, XGBoost, neural network.

Constraint 1 - interpretability: regulators and customers can challenge a blocked transaction. “The model said so” is not a legal answer. We need to be able to say “this was flagged because the merchant category is unusual for you and the amount is 12x your average.” Neural networks cannot produce this explanation cleanly. Logistic regression can, but is too simple to capture non-linear fraud patterns. Tree-based models (random forest, XGBoost) produce feature importance scores and individual decision paths that are inspectable.

Constraint 2 - latency: inference must be under 100ms including feature lookup time. XGBoost inference on a single row is microseconds. A deep neural network forward pass is 10-50ms. The neural network eats most of the latency budget before features are even assembled.

Constraint 3 - class imbalance: fraud is 0.1% of transactions. XGBoost has a native scale_pos_weight parameter that upweights the minority class during training. Neural networks require more manual handling (custom loss functions, oversampling).

Conclusion: XGBoost. It wins on interpretability, latency, and imbalance handling for this specific problem. Neural networks would be the answer if we were processing images of cheques or sequences of transactions over time - but not for a single tabular transaction.

Analysis 3: What metric do we use to evaluate it?

Question asked: is accuracy a valid metric here?

No. A model that predicts “not fraud” for every single transaction achieves 99.9% accuracy while catching zero fraud. This is the class imbalance problem from the statistics section.

Metrics that actually matter:

• Precision: of all transactions we flag as fraud, what fraction are actually fraud? Low precision = we are blocking legitimate purchases and angering customers.
• Recall: of all actual fraud, what fraction do we catch? Low recall = fraud slips through and the bank loses money.

These are in tension. Making the model more aggressive raises recall (catch more fraud) but drops precision (more false positives). The right threshold depends on the business cost of each error type. This is a business decision, not a technical one - but the analyst needs to frame it correctly before anyone can make it.

Analysis 4: XGBoost sees global patterns - what about per-user behavior?

Problem identified: XGBoost trains on all users combined. It learns that certain combinations of features tend to be fraud across the whole population. But it cannot express “this transaction is unusual for this specific user.”

A user who always spends ₹200-500 at local grocery stores making a ₹35,000 purchase at an overseas electronics retailer looks unremarkable to XGBoost globally - other users make large electronics purchases all the time. But that deviation from this user’s personal baseline is exactly the kind of signal that catches account takeover fraud.

Question asked: how do we quantify “unusual for this user”?

We compute a behavioral anomaly score: how far does this transaction sit from the user’s historical transactions in feature space? This is a nearest-neighbor problem - find the most similar past transactions for this user, measure the distance.

Question asked: exact nearest-neighbor or approximate?

Exact nearest-neighbor compares the new transaction against every stored historical transaction - O(n·d) per lookup where n is the number of past transactions and d is the number of features. At real-time scale this is too slow. More importantly, in high-dimensional feature spaces, exact nearest-neighbor becomes geometrically unreliable anyway (the curse of dimensionality - all points start looking roughly equidistant). Approximate nearest-neighbor (HNSW, LSH) finds a neighbor nearly as close in O(log n) time. For the purpose of “is this transaction anomalous?”, nearly as close is completely sufficient.

Conclusion: the ANN behavioral anomaly score becomes one feature fed into XGBoost. XGBoost now has both global fraud signals and per-user deviation as inputs. They are not alternatives - they answer different questions, and both answers go into the same model.

Analysis 5: Which features should go into XGBoost?

Question asked: should we include every available feature?

No. More features are not always better. Irrelevant features add noise that causes overfitting - the model memorizes noise in the training data and performs worse on new transactions.

Tool from information theory: mutual information between each feature and the fraud label measures how much knowing that feature reduces uncertainty about whether a transaction is fraud. A feature with zero mutual information is useless. Features with high mutual information are the ones to keep.

This gives a principled, quantitative way to decide what goes in - not intuition, not trial and error, not throwing everything at the wall.

Analysis 6: How does this run under 100ms?

Problem identified: several features require looking up a user’s history - average transaction amount, most common merchant types, time since last transaction. Querying a database for this during inference would take 50-200ms on its own, blowing the latency budget entirely.

Solution: pre-compute these features in a background process and store them in Redis (an in-memory cache). At inference time, the feature service reads from Redis in under 1ms, not from the database. The ANN index for behavioral similarity is also pre-built and kept in memory.

Model retraining happens asynchronously every few hours on a batch of recent labeled transactions - not in the real-time inference path.

Analysis 7: What does statistics warn us about in training data?

The training dataset has a structural flaw: it only contains detected fraud. Fraud that slipped through undetected was labeled “legitimate” and trained the model to ignore those patterns. This is survivorship bias. The model will be systematically blind to novel fraud patterns that past detection missed, and real-world recall will be lower than test-set recall suggests. This is not fixable entirely - it is an inherent limitation of the data - but it is important to know when interpreting evaluation results.

The full pipeline

Why every decision was forced by a previous one

The 100ms constraint forced pre-computation into Redis, which determined what features were feasible to include. The interpretability requirement ruled out neural networks, which determined the model family. The class imbalance forced a choice of evaluation metric, which shaped how the threshold is tuned. The global-vs-local gap in XGBoost forced the addition of the ANN behavioral score. The high dimensionality of feature space forced approximate rather than exact nearest-neighbor. The mutual information analysis determined what actually enters the model.

None of these were independent stylistic choices. Each was the answer to a specific question forced by a previous constraint. This is what cross-domain technical reasoning actually looks like.

A Worked Example: The Same Problem, Different Framing

The XGBoost solution above detects fraud by examining one transaction at a time. Now change one thing about the problem statement, and every conclusion changes.

New problem: detect account takeover fraud, where a fraudster gains access to a legitimate user’s account and gradually tests it before draining it. The pattern looks like: small test transaction at an unfamiliar merchant → second small transaction succeeding → larger transaction → large withdrawal. No single transaction in this sequence is individually suspicious. The fraud only becomes visible as a pattern across time.

The input is now a sequence of the user’s last N transactions in order. The order and temporal dependencies between transactions are what carry the signal. This is structurally different from the previous problem.

Analysis 1: What kind of ML problem is this now?

Question asked: is the data still tabular?

No. The input is a sequence where the relationship between positions matters - transaction 3 means something different depending on what transactions 1 and 2 were. XGBoost treats features independently. You could engineer lag features manually (“was the previous transaction at an unfamiliar merchant?") but this only captures fixed-window patterns you thought to define in advance. Arbitrary-length sequential dependencies - a fraudster who tests over 2 transactions vs. 5 vs. 10 - cannot be captured this way.

Conclusion from ML map: the data has temporal sequential structure → this is a sequence modeling problem → neural network.

Analysis 2: Which neural network architecture?

Options: RNN (LSTM / GRU), Transformer, 1D CNN.

RNN (LSTM / GRU): processes the transaction sequence one step at a time, maintaining a hidden state that summarizes everything seen so far. Good at capturing sequential dependencies, but struggles with very long sequences because the hidden state becomes a bottleneck - early transactions get compressed and eventually forgotten.

Transformer: uses self-attention, which lets each transaction directly attend to every other transaction in the sequence regardless of distance. Better at capturing long-range dependencies. Requires more memory (attention is O(n²) in sequence length) but sequence length here is bounded - a user’s last 50 transactions - so this is manageable.

1D CNN: applies convolutional filters across the sequence to detect local patterns. Fast and parallelizable, but fundamentally local - it detects patterns within a fixed window and cannot capture dependencies across the full sequence.

Conclusion: Transformer is the right architecture for variable-length pattern detection across a bounded sequence. LSTM is acceptable if latency or memory are more constrained.

Analysis 3: Does the latency constraint change?

Question asked: does every transaction need a sequence model decision in under 100ms?

Not necessarily. Account takeover fraud involving a slow multi-step test sequence does not require a blocking decision at each individual transaction. The first small test transaction looks legitimate - blocking it would generate too many false positives and anger customers. The value of the sequence model is catching the pattern by the time the large transaction arrives, or flagging the account for enhanced monitoring after step 2.

This means the sequence model can run asynchronously - not in the real-time payment hot path, but as a background process that updates a risk score for each account every few minutes. This relaxes the latency constraint significantly and opens up slower, more powerful architectures.

The XGBoost model still runs synchronously at < 100ms for every transaction. The Transformer runs asynchronously and updates a “account risk level” feature in Redis. XGBoost reads this pre-computed risk level as one of its input features - the two models work together rather than competing.

Analysis 4: What is the training target?

Question asked: what does “fraud” mean in the training data for a sequence model?

In the single-transaction XGBoost case, the label was simple: this transaction was confirmed fraud or not. In the sequence case, the label must be assigned to the sequence, not to an individual transaction. You need to label sequences like “this series of 8 transactions ended in account takeover” - which requires forensic reconstruction of fraud cases after the fact.

This makes training data much harder to construct. Account takeover cases need to be identified retroactively, the full transaction sequence recovered, and labeled consistently. The training signal is sparser and noisier than single-transaction labels.

This is a statistics problem: sparse positive labels (account takeover is even rarer than transaction-level fraud), noisy label construction, and the survivorship bias problem compounds - sequences that were interrupted by existing fraud detection rules never fully developed, so the training set underrepresents the early-stage patterns most worth learning.

Analysis 5: How does interpretability change?

Question asked: when the Transformer flags an account, can we explain why?

This is where the neural network approach loses ground. A Transformer’s attention weights show which transactions it attended to most when making its decision, which provides some interpretability (“the model focused on the transaction at 2am followed by the transaction at the unfamiliar merchant two hours later”). But this is far weaker than the XGBoost explanation for a single transaction. Regulators may be less satisfied.

Conclusion: if the sequence model is used for real-time payment blocking, the interpretability gap is a serious problem. If it is used for background account monitoring and risk scoring - where the decision is “flag this account for a human analyst to review” rather than “automatically block this payment” - the interpretability requirement is less strict, because a human makes the final blocking call.

The updated pipeline

What changed and why

The core insight: the problem statement changed by one sentence - “examine one transaction” became “examine a sequence of transactions” - and the entire technical stack changed with it. Same domain, same data source, completely different architecture. The analysis process is identical; the inputs to the analysis are different, so the outputs are different.

This is why problem framing is the first and most important step. A small imprecision in how you state what you are trying to detect leads you to build the wrong system with great technical rigor.

Going further: MDPs, bandits, and online learning

The Transformer in the second variant still has a fundamental limitation: it is passive. It observes the transaction sequence and outputs a fraud probability. But account takeover is an interactive problem - at each step you have a choice about what to do, and the fraudster responds to your choices. Someone testing a stolen card who hits an OTP friction step may abandon the account entirely. A legitimate user who hits friction verifies and continues. The Transformer ignores this interaction entirely.

MDPs (Markov Decision Processes) capture this properly. The state is the account’s current risk profile and transaction history. The actions are the intervention options: approve silently, add friction, soft-block, flag for manual review, hard-block. The reward captures the asymmetric costs - catching fraud is good, blocking a legitimate user is bad, missing fraud is very bad. The transition captures how the world changes: a fraudster who hits friction may abandon, a legitimate user may verify, the account’s risk level updates after each action.

An RL agent trained on this MDP learns not just “is this fraud?” but “given where we are in the sequence, what intervention produces the best long-run outcome?” This is a richer policy than the Transformer provides. In practice the two work together: the Transformer provides a compressed state representation of the transaction history, and the RL policy decides what action to take given that state.

Contextual bandits sit between the single-transaction XGBoost and the full MDP. A bandit treats each decision independently - given this transaction’s features and fraud score, which intervention leads to the best outcome, learning from feedback across many transactions. It ignores the long-term sequential dependency that the MDP models, but it is substantially simpler to train and more data-efficient. For many real fraud systems, contextual bandits are the practical choice: you want a learned intervention policy, but the full MDP state space is too large to model reliably with limited account-takeover data.

Online learning addresses a different problem altogether: keeping the model current. Fraud patterns shift constantly - fraudsters adapt within days of a new detection pattern being deployed. Batch retraining every few hours is slow. Online learning updates the model incrementally after each labeled transaction. The catch is that fraud labels are delayed - you often do not know a transaction was fraudulent for days or weeks until the customer disputes it. Algorithms designed for online learning with delayed feedback (Follow-the-Regularized-Leader, Passive-Aggressive) handle this, but it is fundamentally a training infrastructure problem, not a modeling architecture problem.

How they all fit in one system:

The Transformer detects the pattern. The MDP or bandit decides the intervention at each step. Online learning keeps everything updated as fraud evolves. These are not competing answers - they operate at different layers of the same system, each solving a distinct part of the problem that the others leave unaddressed.

Before reaching for a specific tool, answer these five questions:

1. What is the input, and what is the desired output? Many problems become clear once you state this precisely.
2. How large is the input, and how fast does it need to run? This constrains the complexity class of your algorithm.
3. Do you need an exact answer, or is an approximation acceptable? Exact methods are often intractable at scale; approximations often suffice in practice.
4. Is the problem continuous or discrete? Continuous problems often yield to calculus-based methods; discrete problems often require combinatorial thinking.
5. What are the consequences of being wrong? High-stakes decisions require interpretability, uncertainty quantification, and robustness. Low-stakes decisions can tolerate black-box accuracy.

Most technical mistakes are not mistakes of execution - they are mistakes of problem framing. The right tool applied to the wrong problem formulation produces wrong answers with great efficiency. Spend more time on questions 1 and 5 than most people do.