The offline sync
Pulling everything to the device before going offline looks like all three vertices at once. It is two different syncs wearing one name, and neither needs more than two.
The objection sounds airtight. A mobile app that works offline must pull the data down first, all of it, complete, and the user is standing right there. Completeness, volume and speed on one progress bar.
Except "the sync" is two different reads wearing one name. The full sync takes everything, whole, and nobody expects it to be quick. Steam copying a library of game saves runs for minutes, and nobody files a bug. That read is completeness and volume, with its own slow clock, openly accepted.
The delta sync is the fast one, and look at what paid for the speed. Completeness stays: every change since last time is taken into account. What shrank is the volume. Only the differences travel, and the list of deltas is the volume dimension, cut down to almost nothing.
That is the speed clause of the article in action. Fast and slow are comparisons, not values, and turning a full sync into a delta sync is precisely the design decision that moves a read from the slow clock to the fast one. Two syncs, two clocks, two vertices each.
The snapshot and the restore
Carrying a full coherent state away, or bringing a system back from a backup. Both read everything, and neither is fast on the interactive clock.
Two objections, one shape. "I need a complete, coherent state on my laptop before the plane takes off." And "a restore has to be fast, and it reads the entire backup."
The snapshot first. You pack your suitcase before leaving, not in the elevator. The state is prepared while the network is still there, whole and coherent, and the preparation takes what it takes. Completeness and volume, on the slow clock, by everyone's agreement. If freshness at the last minute matters, the delta of The offline sync takes over, and it trades volume away instead.
The restore is the same read pointed the other way, with one word doing a lot of smuggling. A restore should be "fast", certainly. Fast compared to what? To a normal backup cycle, to rebuilding by hand, to yesterday's outage. Minutes instead of hours is a triumph. Nobody means fast the way a click is fast, and the operation is exceptional and bounded. Speed relative to the operation, not latency.
Both cases keep completeness and volume and hand back the speed vertex. The third corner was never in the room.
The ad server
Answer in under 100 milliseconds, and the right answer depends on every active campaign. But searching through everything is not reading everything, and the request returns one ad.
This one arrives in its strongest form. An ad request must be answered in under 100 milliseconds. The correct answer depends on the totality of the active campaigns, because missing one campaign means answering wrong. And campaigns accumulate without a ceiling. Complete, unbounded, synchronous. All three, on paper.
The volume vertex is the one that is not actually there. The request searches through every campaign, but it retrieves one ad. Searching through everything is not reading everything. It is exactly what an index is built to do, and the article's own registry list works the same way: the query considers ten million companies and returns a page.
The completeness that remains lives somewhere else, on another clock. The matching index is built ahead of time, in the background. That build read is complete and voluminous and slow, and no user request ever waits on it. The serving read then touches a slice of the finished index. Speed, nothing else.
One workload, two reads. The build read takes completeness and volume on the slow clock. The serving read takes speed on the fast one. Nobody ever served three vertices in a single read.
The in-memory restart
An engine must load its whole dataset before it can serve. Two clocks in one product, and when the slow one is not acceptable, engineers manufacture the deferral rather than serve three vertices.
A pricing engine, a feature-flag service, any in-memory system: it must load its entire dataset before it can answer anything. Until it has loaded, it is down. Everything, whole, and fast, or so it seems.
Split the clocks. In nominal operation the engine answers from memory: completeness and speed on its loaded state, the fast clock, the case the system was built for. At restart it performs a loading read: complete and voluminous, and slow relative to the nominal clock. Everybody accepts that slowness because restarts are rare, and because it is bounded. A warm-up of minutes is life. Three days is an incident.
The telling part is what happens when that slowness stops being acceptable. Nobody responds by building a loader that serves all three vertices. Engineers manufacture the deferral instead: blue-green deployments, warm-up out of traffic, the new instance loading quietly while the old one keeps serving. When a need threatens to demand all three, the need gets redrawn until it drops one. That reflex is the triangle, applied by people who never heard of it.
Real-time analytics
A columnar engine scans billions of rows in under a second. It reads every row but only a few columns, and when it truly needs everything, the whole dataset is one aggregate and volume is one.
The scariest candidate. A columnar engine scans billions of rows in under a second. All the rows, interactively fast, and the volume is plainly there. Doesn't that hold all three corners at once?
It cheats, in the article's favor. The engine reads all the rows but only a few columns. That is a projection again, just sliced the other way, and the completeness vertex quietly leaves the room.
Push harder, then. Imagine the job that genuinely needs every column of every row, the full content, nothing dropped. At that point, look at what is actually being read. It is not a pile of distinct entities anymore. It is one dataset consumed as a single coherent whole, one logical aggregate chopped into rows. Technically a database, actually one big object, and the article sets that case aside as a prerequisite: the triangle speaks about stores of many distinct entities. When the whole store is one object, its volume is one, and the triangle has nothing to say. Not defeated. Out of scope, by its own first bullet.
The unbounded aggregate
A rule set that grows for ten years, read whole and fast. Not a counter-example, a diagnosis. An aggregate with no bound is a pile wearing aggregate clothes.
The sharpest objection, because it aims at the article's own escape hatch. The article says a configuration is one aggregate, so fetching it whole is completeness and speed, and the volume vertex does not apply. Fine. Now let those pricing rules grow for ten years. The read is still coherent over the whole set, still synchronous, and the set is not small anymore. Completeness and speed on an unbounded aggregate is untenable, and the triangle never seemed to flag it.
Look at the volume definition in the article again. Volume is a count with no natural bound, a number that grows because the world keeps turning. The rule set is one object, so its count is one, and nothing here tends toward infinity except the size of a single object. And an object grows because somebody meant it to. Ten years of unexamined growth means nobody was steering.
If this case really contradicted the triangle, you would not see one swelling set. You would see N sets, an endless line of them, and an endless line of independent things is a pile. So an aggregate that grows without bound is a pile wearing aggregate clothes, the exact mirror of the article's configuration table. The triangle quietly demands that aggregates stay bounded, which is what Vaughn Vernon has been preaching as small aggregates all along. Not a hole in the rule. The rule, catching a modeling fault.
The catalog in memory
Loading the whole catalog at startup to compute on it. Whether that is a need depends on what the elements are, independent units or parts of one computation.
An application loads its entire catalog, or its entire graph, into memory at startup, and computes on it all day. Everything, resident, always. Surely that is a need for the whole pile, whole and fast?
It depends on what the elements are, and the question splits the case in two. If they are independent units, products browsed one at a time, nodes consulted individually, then this is a pile, and loading it whole was a comfort, not a need. Pagination and lazy loading were available the entire time. The triangle was never challenged, someone just took the convenient shortcut, which is fine, right up until the pile grows.
If the elements are parts of one coherent computation, a graph that only means something traversed whole, then this is an aggregate. Completeness and speed, perfectly legitimate, no volume in sight. And then The unbounded aggregate applies in full: that aggregate had better stay bounded, or the design has a problem the triangle is precisely built to expose.
The nightly invoices
Every night, walk every purchase of the day and bill it, fast. A composed need, two vertices then two others, and the deadline is throughput, not latency.
Every night, the billing job walks every purchase of the day, reads each one in full, and generates its invoice. All the data, complete objects, and it had better be done by morning. That sounds like the triangle's nightmare: volume, completeness and speed in one job.
It is two reads, composed. The first lists what must be billed: many purchases, quickly, as a thin list of references. Volume and speed, no completeness. The second takes each purchase and generates its invoice: the whole object, handled fast, one at a time. Completeness and speed, no volume. No single read in the pipeline ever carries three vertices.
The deadline is real, and it is the other speed. If the nightly run takes more than 24 hours, you are in genuine trouble. But that budget is throughput, the total work per night, not the latency of any read, and the article is explicit that the speed vertex means latency. You do get one night of grace a year, when the clocks fall back and hand the job a 25-hour day.
The composed shape is also just better engineering. The second phase parallelizes, so a hundred times more invoices does not mean a hundred times more night. The three-vertex monolith it replaced would be capped by whatever its one technology could serve.