What these models can
and cannot tell you.
Tradeoff Studio is only useful if you know how far to trust it. This page describes how the models are built, where the sources come from, who checks the claims, and what the whole thing is not able to do.
These are teaching models, and they are deterministic on purpose.
Every simulation here runs the same way twice. Give it the same inputs and you get the same output, which means you can change one condition and attribute the whole difference to that change. That is the entire point: the value is in the comparison, not in the absolute numbers.
Real systems are not deterministic. Queues have arrival distributions, garbage collectors pause at inconvenient moments, and the network does things no model anticipates. Determinism here buys clarity and costs realism, and that is a trade I made deliberately.
The assumptions are on screen, not buried in the engine.
Processing times, capacity, timeouts, retries, pool sizes, failure windows — these are all values you can see and edit. Scenario Studio records whether a timing was estimated or measured, because those are very different kinds of number and a model that hides the difference is flattering you.
Technology labels never apply a hidden multiplier. Naming a component “PostgreSQL” does not silently make it faster than one named “database”. If a number changes the result, you typed it.
The trade-off scores on pattern pages work differently, and it is worth being blunt about them: they are authored, contextual values on a 0–100 scale, written to show a direction of change within one stated scenario. They are not benchmarks, probabilities or predictions, and averaging them would be meaningless.
What the models leave out.
Scenario Studio models one acyclic business flow per design over a short run. It does not model latency distributions, query plans or lock contention, disk and network bandwidth, memory pressure, garbage collection, autoscaling, transactional correctness, idempotency, or cache invalidation. The guided pattern experiments are narrower still — each one isolates a single behaviour and ignores everything else.
The full list of boundaries lives with the implementation, in the technical notes, rather than being summarised here. That is so it can be updated when the engines change. It is my job to keep the two in step; nothing enforces it automatically.
A simulated result is not evidence about your system.
You can cite Tradeoff Studio as what it is — an educational model of a mechanism. What you cannot do is treat an outcome here as evidence that a production system will behave the same way. The model does not know your traffic shape, your data, your hardware or your failure history.
A model is good for finding the question. It can tell you which variable is worth instrumenting and which interaction is worth testing. Answering the question still takes load testing, profiling and telemetry from the real thing.
Where a canonical source exists, I try to cite it.
When a pattern has an identifiable origin — Nygard on circuit breakers, Garcia-Molina and Salem on sagas, Young and Fowler on CQRS, Fowler on the strangler fig — I link that directly rather than paraphrasing someone else’s paraphrase. Where a claim is about how something actually behaves in practice, vendor and practitioner documentation is often the better source, and I use it alongside.
This is about traceability, not citation theatre. Two or three sources that genuinely support the claims on a page are worth more than a long list that mostly signals effort. If a page makes a claim I could not trace, that is a defect — tell me.
When credible sources genuinely disagree about something that changes the conclusion, I would rather show the disagreement on the page than resolve it by assertion.
Who reviews this: one person, and you should know that.
Tradeoff Studio is built and maintained by one person. Before something is published I check it against its sources and against what the code actually does. That is author review. It is not independent peer review, there is no editorial board, and no one else signs off on a claim before it goes out.
The build does enforce some structure: content schemas are validated at build time, so a pattern missing its sources, its counter-indications or a valid related link fails the build rather than reaching the site. That catches missing pieces. It cannot tell whether a sentence is true — only a person can do that, and here that person is me.
Content also moves through explicit editorial states, so unfinished material can sit in the repository without appearing in navigation or search until it is ready.
How I use AI tools.
I use AI-assisted tools while building Tradeoff Studio — for coding, testing, research assistance, critique and editing. They help me work faster. They do not decide what is true, and I am responsible for everything published here.
AI is also not part of the product. Nothing on this site calls a model while you use it. Every simulation, recommendation and assessment is deterministic code running in your own browser, which is why it keeps working with the network off and gives the same answer every time.