TL;DR — Probability is the algebra of uncertainty, and every modern intelligent system — fraud detectors, search rankers, recommendation engines, A/B testing platforms — is a probability engine under the hood. This post walks from sample spaces and Bayes’ theorem to the production patterns you can actually ship, with concrete examples from Stripe Radar, Netflix’s ranking stack, and Bayesian experimentation at Booking.com.

Why Probability Still Matters in the Age of LLMs

Every time you press “send” on a payment, a probability model decides within milliseconds whether you’re a fraudster. Every time Netflix queues a thumbnail, a Bayesian ranking model estimates the probability you’ll click it. Every time Booking.com runs an experiment, a probability calculation tells them whether a 1.3% lift is real signal or noise.

The narrative that “deep learning killed statistics” was always marketing. In practice, the systems that ship to production are probability engines with neural networks inside them, not the other way around. A logistic regression is just a model where the output is interpreted as a probability. A classifier head on a transformer is a softmax over a categorical distribution. Even the cross-entropy loss that trains your model is the negative log-likelihood under a Bernoulli or multinomial.

If you understand probability deeply, you can debug these systems, reason about their failure modes, and design the next one. If you treat it as a checkbox you ticked in college, you’ll spend your career confused about why a model that “looked great offline” misbehaves in production.

This post is a working engineer’s path through probability — starting from the basics and ending at the production patterns that power the systems you use every day.

The Foundations: Sample Spaces, Events, and Measures

Probability starts with a sample space $\Omega$, the set of all possible outcomes of some experiment. Flipping a coin: $\Omega = {H, T}$. Rolling a six-sided die: $\Omega = {1, 2, 3, 4, 5, 6}$. The set of all HTTP requests arriving at a login endpoint in a minute: $\Omega = \mathbb{R}_{\geq 0}^n$.

An event is a subset of $\Omega$ — something you might want to bet on. “The die rolls a 6” is ${6}$. “The die rolls an even number” is ${2, 4, 6}$. “A login request arrives within 100ms of the previous one” is some measurable subset of request timestamps.

A probability measure $P$ assigns a number in $[0, 1]$ to each event such that:

  1. $P(\Omega) = 1$ (something happens)
  2. $P(A \cup B) = P(A) + P(B) - P(A \cap B)$ (additivity)
  3. $P(A) \geq 0$ for all $A$ (non-negativity)

That’s it. Everything else is consequences of these three axioms (Kolmogorov, 1933). The reason your textbook spent 300 pages on probability wasn’t because the axioms are complicated — it’s because the consequences are rich, surprising, and occasionally counterintuitive.

Conditional Probability and Independence

Two events $A$ and $B$ are independent if $P(A \cap B) = P(A) \cdot P(B)$. Intuitively, knowing $A$ happened tells you nothing about $B$. Coin flips are independent. Drawing cards without replacement is not.

Conditional probability is defined as:

$$P(A \mid B) = \frac{P(A \cap B)}{P(B)}$$

This says: restrict your sample space to outcomes where $B$ happened, and recompute the probability of $A$ within that restricted space. Most of what you’ll do in production is some form of conditioning — restricting attention to a slice of the world.

The Law of Total Probability

If ${B_1, B_2, \ldots, B_n}$ partitions $\Omega$, then for any $A$:

$$P(A) = \sum_{i=1}^{n} P(A \mid B_i) \cdot P(B_i)$$

This is the workhorse of mixture models and hierarchical Bayesian inference. In a fraud detection system, you might partition the population into users from different countries, age bands, and device classes, then weight the per-segment fraud rates by segment size. That’s the law of total probability.

Bayes’ Theorem: The Single Most Useful Identity

From the definition of conditional probability, two ways of writing $P(A \cap B)$ must be equal:

$$P(A \mid B) \cdot P(B) = P(B \mid A) \cdot P(A)$$

Rearranging gives Bayes’ theorem:

$$P(A \mid B) = \frac{P(B \mid A) \cdot P(A)}{P(B)}$$

This looks trivial. It is mathematically trivial. It is also the foundation of modern inference, scientific reasoning, medical diagnosis, spam filtering, and most of what gets called “AI” in production. Treat it accordingly.

The terms have names you’ll see everywhere:

  • $P(A)$ — the prior: what you believed about $A$ before seeing the data.
  • $P(B \mid A)$ — the likelihood: how probable the data is, given $A$.
  • $P(B)$ — the evidence: a normalizing constant, often the hard part to compute.
  • $P(A \mid B)$ — the posterior: your updated belief after seeing the data.

A Concrete Bayes Example: Spam Filtering

A user reports that 0.1% of emails are spam. Your spam filter looks for the word “free” — 50% of spam contains it, but only 1% of legitimate email does. An email arrives containing “free”. What’s the probability it’s spam?

  • $P(\text{spam}) = 0.001$
  • $P(\text{“free”} \mid \text{spam}) = 0.5$
  • $P(\text{“free”} \mid \text{legit}) = 0.01$

By Bayes:

$$P(\text{spam} \mid \text{“free”}) = \frac{0.5 \cdot 0.001}{0.5 \cdot 0.001 + 0.01 \cdot 0.999} \approx 0.048$$

About 4.8%. Counterintuitive — “free” feels spammy, but the base rate of spam is so low that even a strong signal doesn’t move the needle much. This is the base rate fallacy, and it bites production systems constantly. Fraud rates are 0.1%–1%, not 50%, so even very predictive features produce posterior probabilities that look smaller than engineers expect.

Random Variables and Distributions

A random variable is a function from the sample space to a measurable space — usually $\mathbb{R}$ for continuous variables or a countable set for discrete ones. The randomness lives in the outcome, not the variable; the variable is just a labeling.

The distribution of a random variable is the probability measure induced by that function. For discrete variables, it’s a probability mass function (PMF): $p_X(x) = P(X = x)$. For continuous variables, it’s a probability density function (PDF) $f_X(x)$, where $P(a \leq X \leq b) = \int_a^b f_X(x) , dx$.

The Distributions That Show Up in Production

DistributionWhen You Use It
Bernoulli($p$)Binary outcomes: clicked/not clicked, fraud/not fraud
Categorical($p_1, …, p_k$)Multi-class outcomes with $k$ mutually exclusive classes
Poisson($\lambda$)Count of events in a fixed interval: requests/min, errors/hour
Exponential($\lambda$)Time until next event: inter-arrival times, time-to-failure
Normal($\mu, \sigma^2$)Aggregated measurements, residuals of well-behaved processes
Beta($\alpha, \beta$)Probability of a probability: Bayesian priors for $p$
Dirichlet($\alpha$)Distributions over probability vectors: topic models, bandit priors
Gamma($k, \theta$)Positive continuous values with skew: latency, file sizes, wait times

The Poisson/exponential pair is the mathematical backbone of queueing theory, which is the mathematical backbone of capacity planning. If you’ve ever used Little’s law to size a worker pool, you used $L = \lambda W$ — and both $\lambda$ (arrival rate) and $W$ (time in system) are probability statements.

The Beta distribution is the workhorse of Bayesian A/B testing. If you’ve ever seen an experiment platform output something like “variant B has a 4.2% conversion rate with a 95% credible interval of [3.8%, 4.6%]”, the interval came from a Beta posterior. Stripe’s experimentation documentation walks through exactly this style of analysis.

Patterns in Production: Where Probability Ships

Theory is fine, but the reason you read engineering blogs is to see how things actually work. Here are four production patterns where probability is the load-bearing wall.

1. Fraud Detection at Stripe Radar

Stripe Radar is one of the most consequential probability systems on the internet — every payment that hits Stripe goes through it. The architecture is a stack of probabilistic models, each conditioned on different slices of context.

A simplified version looks like:

  1. A calibrated logistic regression produces $P(\text{fraud} \mid \text{card}, \text{merchant}, \text{behavior})$.
  2. A gradient-boosted tree ensemble captures non-linear interactions the logistic regression misses.
  3. A Bayesian hierarchical model shrinks per-merchant fraud rates toward a global prior, so a new merchant with 3 transactions doesn’t get a wildly overconfident fraud rate.
  4. A mixture model separates “this looks like fraud” from “this looks like a compromised legitimate user” — distinct populations with distinct signals.

The output isn’t a binary decision. It’s a calibrated probability that feeds a cost-sensitive threshold: review if $P(\text{fraud}) \cdot \text{loss} > \text{review cost}$. The whole pipeline is a probability calculator, updated continuously as new labels stream in from chargebacks. The engineering details are public in Stripe’s sessions on machine learning.

2. Bayesian Ranking at Netflix

Netflix’s thumbnail ranking system is a textbook example of probability under uncertainty. For each user-asset pair, they estimate $P(\text{play} \mid \text{user}, \text{asset}, \text{context})$. But “context” is itself a probability distribution: device, time of day, session length so far.

The model uses Thompson sampling: instead of picking the asset with the highest expected probability, sample from the posterior and pick the sample’s argmax. This gives exploration for free — assets with uncertain posteriors get tried occasionally, while assets with tight posteriors dominate when their expected value is high.

The Netflix engineering team has written publicly about how this kind of posterior-sampling ranking outperformed greedy approaches in long-term engagement metrics. The intuition: greedy ranking over-exploits assets that happened to win a small sample early, and never recovers.

3. Bayesian A/B Testing at Booking.com

Booking.com runs thousands of experiments concurrently. Frequentist A/B tests, the kind that give you a $p$-value, have well-known pathologies at this scale — peeking, multiple comparisons, and the fact that $p < 0.05$ doesn’t mean “this variant is better”.

Their experimentation platform uses Bayesian methods: each variant gets a posterior over its conversion rate, and decisions are made on expected loss (“how much conversion rate do I expect to lose if I ship variant B over variant A?”). If expected loss is below some threshold, ship. This avoids the $p$-value trap entirely and gives product managers an intuitive quantity to reason about.

The mathematics are documented in a great paper by Bernardo et al., and the production implementation pattern is summarized in Booking’s experimentation talks.

4. Anomaly Detection with Poisson Processes

Monitoring systems — Datadog, Prometheus, internal SLO dashboards — are probability systems. An alert fires when some metric’s $p$-value under a null model of “everything is fine” drops below a threshold. The null model is usually a Poisson or Gaussian process fit to historical traffic.

The hard parts:

  • Concept drift: traffic patterns change, so the null model needs to be re-fit or made adaptive.
  • Multiple testing: if you monitor 10,000 metrics, even at $\alpha = 0.001$ you’ll get 10 false alarms per snapshot. Bonferroni, Benjamini-Hochberg, and Bayesian shrinkage are all probability tools to manage this.
  • Alert fatigue: a noisy posterior distribution produces noisy alerts. Hierarchical Bayesian models — where each metric borrows strength from a global prior — produce tighter, more useful posteriors.

Prometheus’s z-score and quantile_over_time operators are essentially queries over empirical posterior distributions.

Architecture: A Reference Probability Pipeline

Here’s a pattern I’ve shipped three times and seen shipped twice more. The job is: given a stream of events with partial labels, produce well-calibrated probability estimates in near-real-time.

┌─────────────────────────────────────────────────────────────┐
│                  Raw event stream (Kafka)                   │
└──────────────────────────────┬──────────────────────────────┘
                               │
                  ┌────────────▼─────────────┐
                  │   Feature extraction      │
                  │   (Flink / Beam / Spark)  │
                  └────────────┬─────────────┘
                               │
                  ┌────────────▼─────────────┐
                  │   Online model scoring    │
                  │   (logistic / GBT / NN)   │
                  └────────────┬─────────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
   ┌──────────▼────────┐ ┌─────▼──────┐ ┌───────▼────────┐
   │  Calibration       │ │ Threshold  │ │  Posterior      │
   │  (Platt / isotonic)│ │ + cost     │ │  update (Beta)  │
   └──────────┬────────┘ └─────┬──────┘ └───────┬────────┘
              │                │                │
              └────────────────┼────────────────┘
                               │
                  ┌────────────▼─────────────┐
                  │   Decision / Action      │
                  └──────────────────────────┘

Three things make this work:

  1. Calibration is separate from discrimination. A gradient-boosted tree might rank perfectly but produce uncalibrated scores. A Platt scaling or isotonic regression layer maps scores to probabilities without changing rankings. This separation is described in Stanford’s ML calibration notes and is mandatory in any serious production system.
  2. Cost-sensitive thresholds are where business decisions meet probability. The same model can serve fraud review (where the cost of a false negative is high) and ad ranking (where the cost of a false positive is low) by simply changing the threshold.
  3. Posterior updates close the loop. Each new labeled event updates a Beta posterior over the model’s recent calibration error. When that posterior drifts, you trigger a recalibration job.

Common Pitfalls and How to Dodge Them

Confusing Probability and Frequency

A 60% probability of rain tomorrow does not mean it will rain 60% of the time. It’s a degree of belief under a specific model. The frequentist interpretation requires a hypothetical infinite ensemble of tomorrows, which doesn’t exist. This matters when you explain model outputs to non-technical stakeholders — they will misuse “probability” if you don’t disambiguate.

Treating Softmax Outputs as Probabilities

Neural network classifiers often output values that sum to 1, but they are not necessarily calibrated probabilities. A model can output 0.9 and be right 70% of the time, not 90%. Always measure calibration — expected calibration error, Brier score, or reliability diagrams — before trusting the outputs.

Ignoring Priors in Low-Data Regimes

If you have 3 fraud cases and 10,000 legitimate ones, your empirical fraud rate is 0.03%, and your model’s confidence will be wildly overfit. A Bayesian framework that shrinks toward a reasonable prior — perhaps the industry-wide fraud rate — is dramatically more robust. This is the single biggest reason Bayesian methods dominate in low-data production systems.

Forgetting That Conditional Independence Is Almost Never True

Naive Bayes assumes features are conditionally independent given the class. This is rarely true — in fraud, having a high-risk IP and a high-risk device class are correlated. Naive Bayes still often works because it only needs the ranking of probabilities to be correct, not the exact values. But if you need calibrated probabilities, you need a model that handles dependencies.

Key Takeaways

  • Probability is the algebra of uncertainty. Every production intelligent system is a probability engine with neural networks, gradient-boosted trees, or rule-based logic inside it.
  • Bayes’ theorem is the single most useful identity in applied statistics. Learn to read $P(A \mid B) = \frac{P(B \mid A) P(A)}{P(B)}$ the way you read a function signature — instantly, without thinking.
  • Base rates matter more than signals. A 50%-predictive feature on a 0.1% base rate produces a 4.8% posterior, not 50%. This is the source of countless “the model is broken!” debugging sessions.
  • Calibration is a separate concern from discrimination. A great ranker that outputs uncalibrated scores is dangerous in any cost-sensitive application.
  • Posterior distributions > point estimates. Thompson sampling, expected loss for A/B tests, and Bayesian monitoring all beat their frequentist counterparts in production because they expose uncertainty as a first-class quantity.
  • The hard part is the evidence, $P(B)$. Variational inference, MCMC, and Laplace approximation are different ways of computing (or approximating) the normalizing constant in Bayes’ theorem — and they’re why “Bayesian” used to mean “slow” until the 2010s.

Further Reading