Counting the distinct visitors to a large site with an exact algorithm costs O(n) memory. HyperLogLog counts the same set with 1–2% error at a fraction of the cost. The approximate answer is the right engineering answer.
Most engineers treat correctness as non-negotiable. They ship exact algorithms because "wrong" sounds indefensible. Then latency budgets slip, memory bills climb, and the service degrades under load. The correct answer arrived too late to matter.
This article dissects AT9 — Correctness vs Performance. It names the dial, the failure mode on the wrong side, and the signal that tells you the tradeoff is in play right now.
The dial
AT9 is a single dial with two poles.
A correct system always produces the right answer. A performant system produces the answer quickly. When computation is expensive, these conflict. Approximation algorithms sacrifice correctness for speed. Exact algorithms sacrifice speed for correctness.
Every design decision on this axis chooses a position between the two. There is no neutral centre. Refusing to choose picks a default — usually the exact algorithm, at whatever performance cost the workload extracts.
The dial is not a compromise between two flaws. It is a match between the algorithm and the cost of a wrong answer.
Where the dial appears in production
The same tradeoff shows up across problems that look unrelated.
Bloom filters. A Bloom filter can say "definitely not in set" with certainty. It may produce false positives — reporting a member that is not there. In exchange, it holds a large set in a fraction of the memory an exact structure would demand. Approximate correctness for dramatic space savings.
HyperLogLog. Counting distinct elements exactly requires O(n) memory — one slot per unique element. HyperLogLog produces the same count with 1–2% error at a small constant memory footprint. The count is not exact. It is accurate enough for every decision that depends on it.
Nearest neighbour search. Exact nearest neighbour requires scanning every vector in the dataset. An HNSW index returns an approximate nearest neighbour in sub-linear time. The result is not guaranteed to be the closest point. It is guaranteed to be a close point, delivered fast enough for interactive search.
Driver matching in ride-sharing. Optimal matching between riders and drivers is NP-hard. A greedy approximate match runs in milliseconds. The optimal match would arrive minutes after the rider stopped waiting.
Different problems. Same dial. Each design chose approximate over exact because the exact algorithm did not fit the requirement.
Setting the dial
The question that sets the dial is not "how accurate can we be." It is: what is the cost of the wrong answer?
The cost is asymmetric across domains. Ask the question domain by domain.
In financial settlement, a wrong answer moves money to the wrong account. The cost is high and recovery is expensive. Use exact algorithms regardless of performance cost. AT9 resolves toward correctness.
In search ranking, a wrong answer returns the second-best result instead of the best. The user rarely notices. The cost is low. Use approximate algorithms to meet the latency budget. AT9 resolves toward performance.
In distinct visitor counts for a dashboard, a wrong answer is off by 1%. The product decision — is traffic up or down — is unchanged. Use approximate counting. AT9 resolves toward performance.
The dial does not have a universal setting. Every workload sets it separately, based on the cost function of that workload's wrong answers.
Approximation is not failure
The reflex to treat approximate answers as second-class is the most expensive mistake on this axis.
A recommendation engine that is 95% as good as the optimal recommendation at 0.1× the computational cost is not a compromise. It is a correct engineering decision. The tradeoff is explicit. The answer is the right engineering choice for the requirements.
The wrong framing sounds like this: "We should use exact matching because it is more accurate." The right framing sounds like this: "The exact algorithm costs 10× more compute and 200ms more latency. The approximate algorithm produces answers that are 95% as good. The 5% loss costs us nothing measurable. The 200ms costs us conversions. Use the approximate algorithm."
The engineering decision is not accuracy. It is the ratio of accuracy loss to the resource savings that loss buys.
The failure mode on the wrong side
Every architecture tradeoff introduces at least one failure mode when the dial is set incorrectly. AT9 exposes FM9 — Silent Data Corruption.
Silent corruption is the failure mode where wrong data propagates without alerts. Nothing crashes. No error is logged. The system continues to run. Downstream consumers treat the wrong answer as authoritative and act on it.
AT9 exposes FM9 whenever the approximation is wrong for the workload it serves.
A Bloom filter with an unacceptable false-positive rate feeds bad "membership" answers into a caller that assumes them true. The caller acts on membership that does not exist. Nothing surfaces the error.
A HyperLogLog counter with an error tolerance that is fine for a dashboard is not fine for billing. Charge the customer for approximate usage and the invoice is wrong every time. No error log fires. The invoice looks like every other invoice.
An approximate nearest neighbour used for content recommendation is fine. The same index used for fraud detection returns "no similar case found" when a similar case exists. The fraud proceeds.
FM9 does not announce itself. It appears as slow drift — reports that stop matching reality, invoices customers dispute, decisions that turn out to have been made on wrong numbers. By the time it surfaces, the corrupted data is downstream in every consumer.
The mitigation is not "use exact algorithms." That resolves AT9 toward correctness at the performance cost the workload could not pay. The mitigation is: know the error bound of the approximation, and know that the error bound is inside the tolerance of every consumer that reads the answer.
If a consumer emerges later that needs tighter accuracy, the approximation is now the wrong choice for that consumer. Revisit AT9 for that path.
The decision protocol for AT9
Apply the general protocol to this specific dial.
Identify the tradeoff in play. When the requirement includes both an accuracy statement and a performance statement, AT9 is in play. When either is silent, ask which one the requirement actually cares about.
Establish what the requirement demands. "We cannot lose a payment" drives AT9 toward correctness. "The feed must load in under 100ms" drives AT9 toward performance. The requirement, not the preference, sets the dial.
Name the cost on the other side. If you chose exact — name the performance cost. Memory footprint, latency, throughput ceiling. If you chose approximate — name the accuracy loss. Error bound, false-positive rate, expected deviation from optimum. If the business cannot accept the named cost, revisit the decision.
Record the decision and the tradeoff. Write an Architecture Decision Record. Future engineers need to know not just that HyperLogLog was chosen but that the 1–2% error was accepted and that any consumer needing tighter accuracy must not read from this counter.
The signal that tells you AT9 applies to your system
Look for one of these three in your current system.
Your accuracy is exact but your latency is unacceptable. Every request runs an algorithm that scans the full dataset. P99 misses budget. The exact algorithm is the bottleneck. AT9 is on the correctness pole and the performance cost is being paid.
Your latency is fine but your memory or compute bill is climbing. The exact algorithm holds one slot per element or scans every vector. The workload grew. The bill grew linearly with it. AT9 is on the correctness pole and the performance cost is now visible as spend.
A downstream consumer complains that numbers do not match. A dashboard says 4.2 million distinct users. Billing says 4.15 million. Fraud says a case was not flagged that clearly matches an existing case. AT9 is on the performance pole and FM9 has surfaced in a consumer whose tolerance is tighter than the approximation's error bound.
Any of the three is a signal that the dial is set and the setting is worth revisiting against the current cost of the wrong answer.
The harder question
The article named the dial and the failure mode. It did not answer the harder question.
Every approximation has an error bound. Every consumer has a tolerance. What is the mechanism that guarantees the two are still in the right relationship a year from now, when new consumers are reading from the same approximate source and the workload has moved?
The full framework treatment — compression blocks, three-level exercises, and the complete AT/FM mapping — is in the Reference Book, Chapter 8 (Architecture Tradeoffs). Free chapter available at computingseries.com/books/ref.