Backend & Distributed Systems

Long-running services with no primary UI of their own. They expose APIs, process events, coordinate workflows, and integrate other systems.

When to look here

• The system is consumed primarily by other systems, not directly by end users
• Multiple services need to coordinate via events or messages
• Throughput, consistency, or availability requirements exceed what a monolith can provide

Patterns in this category

Pattern	Status	Best for
Modular Monolith	Adopt	Default starting point; most "microservices" projects should be this
Microservices	Trial	Large engineering organisations with proven need to scale teams
Event-Driven Architecture	Trial	Asynchronous workflows, decoupling producers from consumers
API Gateway + BFF	Adopt	Many client types (web, mobile, partners) sharing backend services
Workflow Orchestration	Trial	Long-running, human-in-the-loop, or failure-prone processes
Saga Pattern	Trial	Distributed transactions across multiple services where 2PC is unacceptable
Canonical Model + Pluggable Adapters	Adopt	Integration hubs with multiple external formats or protocols (payments, customer data, trade capture)
CQRS with CDC-Driven Read Models	Trial	Read/write separation where the source is a legacy DB or packaged system with no application-level events
Idempotent API	Adopt	Any state-changing API where duplicate execution is unacceptable — payments, account creation, authorizations

Default tech stack

• Languages: Go, Java (Spring Boot), .NET, Node (NestJS)
• Communication: REST + JSON (default), gRPC (internal high-throughput), Kafka or NATS (events)
• Service mesh: Istio or Linkerd, only when service count exceeds ~20
• Workflow engine: Temporal (the modern default)
• Observability: OpenTelemetry → Datadog or Grafana stack

LLM-development fit

Mixed. Individual services are well-handled; cross-cutting concerns (consistency, idempotency, security boundaries, failure modes) need careful human review.