Architecture Tradeoff Explorer

One deployable with local calls and one transaction, or many deployables with network calls and none. The monolith is the default; microservices are the answer to a measured organisational or scaling problem, and to nothing else.

REST exposes resources with stable shapes that proxies and CDNs understand; GraphQL exposes a typed graph that clients query for exactly the fields they need. The decision is about how many client shapes exist and who pays for query flexibility.

Same request/response idea, different transport. REST/JSON is universal and debuggable; gRPC is binary over HTTP/2 with generated typed clients, deadlines and streams. Inside a network you control, gRPC pays off on hot paths; at the edge, REST wins.

The caller waits, or the caller hands the work to a broker and moves on. Synchronous is simpler and consistent; asynchronous decouples rate and availability at the price of eventual state, duplicates and an invisible backlog.

Relational databases make relationships, ad-hoc queries and invariants cheap; document and key-value stores make one access pattern fast by promising nothing else. Choose by access pattern, not by imagined scale.

A queue delivers each message to one of the competing consumers; a topic delivers each message to every subscriber. Queues distribute work; topics broadcast facts. The choice is "how many parties must see this?"

A producer announces what happened and does not know who listens; a caller asks a specific service and waits for the answer. Events give loose coupling and fan-out; requests give immediacy and a clear failure. Most systems use both: a synchronous command, asynchronous consequences.

A cache is a copy that can be lost and is allowed to be wrong for a while; a database is the truth that cannot be lost. Caches buy read latency and fan-out at the price of invalidation; the database pays for durability and consistency with slower reads.

CRUD reads and writes one model through one interface; CQRS splits commands (write model) from queries (read models projected from events). CQRS solves read/write shapes and scaling that diverge; for most applications CRUD with good indexes and a few read queries is the right answer.

Store every change as an immutable event and derive the current state by replay, or store the current state and overwrite it. Event sourcing gives a perfect audit log and temporal queries; state storage gives simplicity and a query you can run today.