English
PortugueseArchitecture sketch
Answer a few questions about your application and get a starting architecture: every box says why it is there, what it costs and when it would be too much. And watch the data move through it.
A starting point for a conversation, not a design review. Generic pieces, no vendors: what matters is the role each one plays.
Start from an example
About the application
01What kind of application?
02How many people use it at the same time, at peak?
At the same time, not per month. A site with 100,000 visits a month usually has fewer than 100 people at once.
03How much downtime can it take?
04Does it mostly read or write data?
05Does it need live updates?
06Does it do heavy work in the background?
07Does it store files people upload?
08Does it need text search?
09Where are the people?
10Who builds it?
11Does it store sensitive personal or payment data?
Health, ID documents, cards. Privacy laws (GDPR, LGPD) and payment rules ask for extra care.
The architecture
3 piecesPick a situation and follow the path, step by step.
Watch the data move
Legend
What you do not need yet
- Load balancerAt 1,000 people at the same time, or when downtime stops being acceptable.
- CachePast 10,000 people at the same time, or sooner if the application mostly reads.
- Read replicasWith mostly reads and more than 10,000 people at the same time.
- Standby databaseWhen the goal is 99.99%. Until then, automatic backups and a tested restore.
- CDNFor public content, a store, people in several countries or many files.
- QueueWhen work appears that does not need to finish before the response.
- Search engineWhen filters are not enough and search needs relevance.
- Real-time gatewayWhen the conversation goes both ways (chat, collaboration).
- WAFWith sensitive data or from 100,000 people at the same time.
- Services by domainWhen several teams need to ship without waiting for each other.
- Second regionOnly if being down while a whole region fails is not acceptable.
Take it to your project
Text version
Components
- Users
- Application (modular monolith) · Single point of failure
- Database · Single point of failure
- Logs and metrics
Connections
- Users → Application (Request and response)
- Application → Database (Request and response)
How it works
The answers go through fixed rules, not AI: the same answers always give the same diagram, and every box can say which answer put it there.
Everything starts from the minimum any application needs: one application, a database with automatic backups, and logs and metrics. Each answer adds only what solves a problem it creates: more people at once asks for several copies and a load balancer; mostly reads asks for a cache and replicas; little tolerance for downtime asks for several zones and a standby database; files ask for their own storage and a CDN.
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.
Nothing you answer leaves the browser. The answers live in the link, which you can share.
Want to understand the rules behind the boxes?
Read the articleFAQ
When are microservices worth it?
When several teams need to ship parts of the product without waiting for each other. With one team, a modular monolith gives the same code isolation at a much lower cost in network, deploys and observability.
When do I need a cache?
When the database starts answering the same question many times: usually with thousands of people at once, or with an application that mostly reads. Before that, a cache only brings the problem of stale data.
What is the difference between 99.9% and 99.99% availability?
99.9% allows about 45 minutes down a month; 99.99%, about 4 minutes. Reaching the second takes several zones, a database with automatic failover and zero-downtime deploys, which adds a lot of cost and care.
What is a queue for in a web application?
To take slow work out of the request: the application stores the task, answers right away, and workers do the work in the background, retrying when something fails.
Does this tool replace an architect?
No. It gives a starting point and a shared vocabulary for the conversation. Data, budget, deadlines and the real team change the answer, and that is where a review by someone with context comes in.