Architecture choice

Almost every project starts with the same forks in the road: monolith or microservices, which database to pick, call the neighboring service directly or through events, a synchronous web stack or a reactive one. A wrong turn at any of them does not show up right away — it shows up six months later, when redoing it is already painful and expensive.

The hard part is that there is no "right" answer outside of context: the microservices that save one project sink another; the ClickHouse that speeds up one system turns out to be an extra dependency in the next. So this section is not about fashion or about "how it is usually done" — it is about criteria: which concrete signals push a fork one way rather than the other, and what each option costs.

Each fork gets its own article with a checklist, selection criteria, and the common mistakes, all worked through on a single running example. The section closes with the article on ADRs: how to record a decision so that a year later you remember not only "what we chose" but "why".

Articles in this section

1. Monolith, modular monolith, or microservices — a "6-point" checklist for the start of a project, a comparison of the three options on a single marketplace case study, and scenarios for moving between them without a rewrite.
2. PostgreSQL or MongoDB: how to make the call — ten criteria for choosing a relational vs document database, the typical antipatterns (Mongo "because NoSQL is trendy", PG "because it's familiar"), and scenarios where both databases work within a single service.
3. PostgreSQL or ClickHouse: when to add OLAP — eight criteria and a checklist: where the line "analytics in PG is still fine" sits, and when it's time to bring in a second store.
4. Search: PostgreSQL FTS or Elasticsearch — what tsvector and pg_trgm can do, where their ceiling is, and when you need a full-blown search engine.
5. Files: in the database or in object storage — the boundary based on size and traffic, two-phase upload, and "database + S3" consistency.
6. Between services: synchronous call or events — criteria for each interaction, with the synchronous saga and RPC-over-Kafka as antipatterns.
7. The web stack: Spring MVC, WebFlux, or virtual threads — which of WebFlux's arguments Loom has closed, and where reactive is still justified.
8. ADRs: how to record architectural decisions — the format, the statuses, when to write one; each fork above deserves a record.
9. What an architect does — and which tasks AI skills cover — the seven responsibilities of the role and which ucp skills automate each.

Related

• Use Case Pattern — the methodology survives each of these modes without a rewrite.
• The PostgreSQL section — the details of ACID, replication, and sharding.
• The MongoDB section — the details of read/write concerns, replica sets, and sharded clusters.
• The C4 model — how to describe a system once the architectural choice has been made.
• AMQP vs Kafka — choosing a broker, if the sync/async fork resolved in favor of events.