How much architecture does your application need? From monolith to two regions in 11 questions

Every architecture conversation reaches a moment when the whiteboard has fifteen boxes: queue, cache, replicas, gateway, three microservices. Each one has a good reason to exist in some system. The question almost nobody asks is whether it has a good reason to exist in this system, now.

Turning that question into rules was the starting point of the Architecture sketch: you answer 11 questions about the application and get a diagram where every box says why it is there, what it costs and when it would be too much. This article explains the rules behind it.

The starting point that is almost always enough

One application, a managed relational database with automatic backups, and logs and metrics. That is all.

It looks small, but it carries much more than we tend to think. A well-indexed database answers thousands of queries per second, and a well-written application serves a lot of people from a single machine. What this design lacks is redundancy: if the application or the database fails, everything fails. And that can be fine. An internal system, a project still being validated or a product that can be down a few hours a month does not need to pay for more.

What each answer changes

Each answer adds only what solves a problem the answer itself creates:

• A thousand people at once, or little tolerance for downtime: several copies of the application behind a load balancer. A single machine has a ceiling and is a single point of failure.
• Ten thousand people at once, or an application that mostly reads: an in-memory cache in front of the database, so it is not asked the same thing a thousand times.
• Mostly reads with ten thousand people: read replicas. Writes still go to the primary.
• 99.99% availability: copies in more than one zone and a standby database that takes over on its own if the primary fails.
• Not even a whole region can take the service down: a second region. It is the most expensive answer in the tool, and the tool says so.
• Files uploaded by people: object storage and a CDN. Files do not live in the database or on the application disk.
• Heavy background work: a queue and workers. The request answers right away and the slow work happens later, retried when something fails.
• Two-way conversation (chat, collaboration): a real-time gateway and pub/sub between the copies. If the server only notifies, server-sent events from the application itself are enough.

The numbers (a thousand, ten thousand) are rules of thumb, not laws. They show the order of magnitude at which each piece starts to pay for itself.

To compare with the starting point: with the answers of an online store on Black Friday (up to 100,000 people at once, 99.99% availability, full search, payment data and several teams), the same questionnaire reaches 16 pieces.

"At the same time" is the number that matters

The most misleading number is the number of users. A site with 100,000 visits a month sounds big, but those visits spread over the month, the day and the hours. What sizes the infrastructure is the peak of people using it at the same time, and it is usually far smaller than the monthly total. That is why the tool asks exactly that, with a hint under the question.

A single point of failure is not always a problem

The diagram marks the pieces whose failure takes everything down. In a small product, the application and the database are marked, and the explanation says that can be acceptable. Availability is expensive, and each extra nine costs more than the last: it is the idea Google's SRE book describes as embracing the right amount of risk instead of chasing 100%. The right question is how much downtime the business can take, and the tool starts from it.

Microservices are a team decision

The most important rule has nothing to do with scale: with one team, the tool recommends a modular monolith, one deployable with clearly separated modules. Services by domain only come in with several teams that need to ship without waiting for each other. Even then, it shows the cost: network, deploys, observability and scattered data. Martin Fowler describes the same pattern in MonolithFirst: microservice stories that worked almost always started with a monolith that grew too big and was split.

What you do not need yet

Under the diagram there is a list of what was left out and what would bring each piece in. For a product with a hundred people at once: no cache, no replicas, no microservices, and the answer that would change each decision. It is the part that helps most in a conversation with the team: it moves "what if we grow?" out of anxiety and into a concrete trigger.

How the tool was built

• Fixed rules, not AI. The same answers always give the same diagram, and every rule has an automated test.
• Each piece with its own color and shape. The color tells the category (entry and network, compute, messaging, data, support), and the shape tells the type: a database is a cylinder, a queue holds its messages in line, a pub/sub topic is a pipe, the cache is a memory chip, file storage is a bucket. You recognize the piece before reading its name.
• Data in motion. The diagram uses React Flow. Arrows show which way data goes, and scenarios such as "open a page" or "upload a file" walk the path one hop at a time: only the piece receiving the data glows, in its own color, with a caption for each step and optional narration.
• Take it to your project. You can download the diagram as PNG, copy the Mermaid code (which renders as a diagram on GitHub and Notion) and download an ADR, the architecture decision record Michael Nygard popularized, with context, decision, pros and cons and when to revisit.
• Nothing leaves the browser. The answers live in the page address: you can reload, bookmark or share the link.

The pieces are generic on purpose: load balancer, cache, queue and replica have been the same concepts for over a decade, on any cloud or your own servers. Choosing the product is the next step, and it depends on things a questionnaire cannot know: the team, the budget, what you already run well.

Try it with your next project: open the Architecture sketch.

Lessons

1. Start with one application, a database with backups, and logs. Every extra piece needs a concrete reason.
2. Size for the peak of people at the same time, not monthly visits.
3. Decide how much downtime the business can take before designing redundancy.
4. Microservices follow the number of teams; with one team, a modular monolith gives the same isolation for less.
5. Also record what was left out and when to revisit it: it turns "what if we grow?" into a clear trigger.

Frequently asked questions

What is the minimum architecture for a web application?

One application, a managed database with automatic backups, and logs and metrics. It carries a lot of traffic; what it lacks is redundancy, which only pays off when downtime stops being acceptable.

When should I use microservices?

When several teams need to ship parts of the product without waiting for each other. With a single team, a modular monolith gives the same code isolation at a lower cost.

When should I add a cache to my application?

When the database starts answering the same question many times: usually with thousands of people at once, or in an application that mostly reads. Before that, a cache only brings the problem of stale data.

How can I generate an architecture diagram from requirements?

The Architecture sketch, at rafaelfachinelli.com/en-US/tools/architecture, does it from 11 questions and exports the result as PNG, Mermaid and an ADR draft. It is free and runs in the browser.

References

• MonolithFirst, Martin Fowler
• Embracing Risk, Site Reliability Engineering (Google)
• Documenting Architecture Decisions, Michael Nygard
• React Flow