About
There are no best practices. Only trade-offs you can defend.
The Architecture Field Guide is a working reference for the decisions that come up again and again when you build software systems — written to be argued with, not recited.
Who writes this
I'm Dan Woytowich, a Principal Cybersecurity Engineer with over twenty years building and operating production systems.
One example of the work behind these pages: the Ontario Notification System, which powers reminders.ontario.ca — the service that lets the public opt in to digital notices for driver's licence and health card expirations, among other government services. The same backend gives internal government entities one shared communication platform and integration layer instead of a dozen parallel ones.
It runs multi-cloud on purpose: each platform's managed services get used where they are genuinely strongest, while data sensitivity, compliance, and Canadian data-sovereignty requirements stay satisfied. That constraint — the cheapest architecture is not the one you are allowed to build — shapes a lot of what is on these pages.
It is also why this guide leans on operational cost and blast radius rather than elegance. Systems that carry government notices to the public have to survive an audit as well as a design review.
Elsewhere: LinkedIn · Pluralsight · woytowich.dan@gmail.com
Why it exists
Most architecture writing sells a conclusion. It tells you to adopt microservices, or event sourcing, or a service mesh, and treats the costs as an implementation detail for someone else to discover in production eighteen months later.
This guide is organised the other way around. Every page states the options, the forces pulling each way, and the conditions under which each choice tends to win. The recommendation comes last and stays narrow, because the honest answer to most architecture questions is "it depends" — and the useful work is making the dependencies explicit enough to argue about.
The intended use is practical: open the relevant page before the design review, so the team argues about the same trade-offs using the same vocabulary instead of trading intuitions.
Editorial rules
Four rules keep the pages honest:
Every option gets its real costs listed. If a section can't name what the recommended choice will cost you, the section isn't finished.
Recommendations are conditional. "Default to Postgres" is a statement about the common case, not a law. The conditions that break the default are stated alongside it.
No vendor placement. Nothing here is sponsored, and no product has paid for a mention. Where specific tools are named it is because they are the ones you will actually meet.
Corrections are edits, not footnotes. When something here turns out to be wrong, the page changes.
How it's built
A static site: hand-authored HTML for the evergreen guide pages, Markdown for the reports, and a small build step that pre-renders every report to its own page so the content is real HTML rather than something assembled in your browser. Served by nginx. No tracking beyond aggregate page counts, no cookies, no advertising.
New reports are published to the RSS feed.
Corrections & contact
Found something wrong, out of date, or missing an important cost? That is the most useful thing you can send. Corrections go to woytowich.dan@gmail.com and get folded into the page itself.