9 Architectural Patterns for Data and Communication Flow

Most systems use more than one communication pattern. A user request may arrive through a gateway, trigger synchronous validation, publish events, and later feed batch analytics. The point of architecture is to match each boundary to the right pattern and tradeoff.

Peer-to-peer

Peer-to-peer systems let nodes communicate directly without a permanent central coordinator. That can improve autonomy and remove a bottleneck, but it shifts complexity into discovery, trust, membership, and failure detection.

API gateway

An API gateway gives clients a single entry point and can centralise routing, authentication, TLS termination, rate limiting, and protocol translation. It is useful when backend services change faster than external clients, but it becomes dangerous if too much business logic or aggregation moves into the edge layer.

Publish-subscribe

Publish-subscribe decouples producers from consumers through a broker or event log. It is strong for fan-out and asynchronous workflows, but it brings operational questions about ordering, replay, duplicate delivery, dead-letter handling, and schema evolution.

Request-response

Request-response is the standard synchronous pattern: a caller sends a request and waits for a reply. It is simple and explicit, but it couples both sides in time and makes latency, timeouts, and ambiguous retries part of the normal design surface.

Event sourcing

Event sourcing stores state changes as an append-only event history rather than keeping only the latest row state. It gives auditability and replay, but it also raises the complexity floor because event schemas, projection rebuilds, and versioning become long-term commitments.

ETL

ETL extracts data from source systems, transforms it into a target shape, and loads it into a destination such as a warehouse. It is effective for analytics and reporting, but the destination is only as fresh as the last successful run, and bad source data or schema drift can quietly poison downstream outputs.

Batching

Batching groups many units of work and processes them together to improve throughput. It reduces per-item overhead, but it adds delay and can increase blast radius if one bad record causes an entire batch to fail or become hard to replay safely.

Stream processing

Stream processing handles records continuously as they arrive instead of waiting for a batch window. It fits telemetry, fraud detection, and near real-time analytics, but it introduces backpressure, late-event handling, checkpoints, and state management concerns that do not disappear just because the latency is lower.

Orchestration

Orchestration uses a central coordinator to drive a workflow across services. That is valuable when step ordering, compensation, and operational visibility matter, but it can also create a central dependency or a distributed monolith if the orchestrator absorbs too much domain logic.

Pattern choice is a boundary decision

No pattern is best in general. The right choice depends on what the boundary needs: low latency, loose coupling, audit history, data reshaping, throughput, or explicit workflow control. Systems stay easier to operate when those tradeoffs are chosen deliberately instead of by habit.