Part VI · Chapter 11 · Choosing · lesson 1
Why every page here carries a date
10 min
Part VI · Chapter 11 · Choosing · lesson 1
10 min
A page you read two years ago gave a managed queue's maximum message size. You believed it, built a chunking layer around it, and the vendor raised the limit the quarter after. Another page named a database's default isolation level; your hosting provider had already changed it. Neither page was lying when it was written. Neither page said when that was.
This is the only track in the subject that answers "which one should I use" out loud. The price of that is a date on every page, and a way for you to recheck it without taking anyone's word.
Every claim in the five lessons after this one belongs to one of two categories, and telling them apart is the entire skill. One category is a property of how concurrency, partitioning or queueing works, and it was true before the product existed. The other is a value somebody at a vendor chose, and can choose differently on a Tuesday with a changelog entry.
Sort these. The ones on the right you can quote in a design document for a decade; the ones on the left need a date beside them or they are rumour.
Not the same thing
A value a vendor selected: a default, a published quota, a price, a tier boundary, or a behaviour that differs between two of their own products.
A consequence of how the thing works. It constrains every product in the category, including ones not written yet.
Which is which? Put each one on a side.
Postgres defaults to read committed
A read-modify-write across two statements can lose an update unless something serialises it
A DynamoDB partition serves a fixed ceiling of write units a second
A hot key concentrates load onto whatever unit the system partitions by
Azure SQL Database creates databases with read-committed snapshot on, and SQL Server does not
A reader that takes locks blocks a writer, and a reader that reads a snapshot does not
The standard tier of this managed queue bills per request above a monthly free allowance
A service credit on a future bill is worth less to you than the revenue the outage cost
The mistake is not believing a documentation page. It is believing a documentation page about your account. Vendor docs state a default; your account, your region and your running process each get a vote, and the number you actually receive is the one after all the votes.
| What you want to know | Where the real answer lives | Not here |
|---|---|---|
| A config default | The running process, queried from a connection your app would use | The docs page, the Helm chart, the ORM's documentation |
| A service quota | Your own account's quota console or API, for your region | The "service limits" documentation page |
| A rate ceiling | A deliberate load test against one key, reading the throttle counter | The marketing page's headline throughput |
| A price | The last bill, divided by the units it covers | The pricing calculator |
| An availability promise | The current agreement document, with its effective date | The number on the product page |
The distinction in every row is the same one: a published figure is a statement about a default or a typical case, and you are not a typical case in whichever dimension is about to hurt you.
Calendar cadence is the weaker half of this. The stronger half is a list of events that invalidate a claim regardless of how recently you checked, because a claim checked last week is void if you upgraded yesterday.
| Claim type | Calendar | Events that void it immediately |
|---|---|---|
| Engine defaults and semantics | Yearly | Any major version upgrade; a move between self-hosted and managed; a new pooler or ORM in the path |
| Account quotas | Quarterly | A new region; a new account; any planned load increase; a quota increase request you filed and assumed was granted |
| Per-partition and burst behaviour | Before you depend on it, and after | A change to the partition key; a new tenant large enough to skew the distribution |
| Prices and tier boundaries | Each billing cycle you read anyway | A contract renewal; a tier change; a vendor pricing announcement |
| Availability agreements | Yearly, and at renewal | Any notice that the terms have been updated; a move to a different tier of the same service |
If that looks like more work than it is: the checks in the first column are mostly one command or one console page. The load test is the one that costs real engineer-days, and it costs them precisely because it is the only check that produces a number nobody published.
Check
Every lesson from here ends with a dated caveat, and that caveat is not a disclaimer. It enumerates the specific claims in that lesson that carry a version or a date, one by one, so you can work down the list rather than re-verify a whole page. A lesson that names a default, a quota or an availability percentage and does not list it there has failed at the thing this track exists to do, and you should treat the unlisted claim as the least trustworthy sentence on the page.
Three habits make the rest of it usable:
The previous version of this subject refused to name products at all. The reasoning was defensible — naming the product dates the page, and a lesson that recommends a vendor ages into an advertisement for a thing that stopped being the right answer.
What that bought was a subject that could not answer the only question most readers arrive with. "Use a durable log" is not an answer; it is the question restated in a tone of authority. A developer who needs to choose between two named systems this week cannot act on it, and the lesson's refusal to choose reads to them as the author not knowing.
So the trade here runs the other way: name the thing, and pay for it with a date, an enumeration of the perishable claims, and a stated criterion so the reasoning outlives the verdict. That is a worse deal than being timeless. It is a much better deal than being useless, and the expiry is visible rather than hidden, which is the part that matters.