2A. Networking and Communication

Every remote call crosses a failure boundary. Protocol choice affects latency, connection state, intermediaries, scalability, and failure behavior. Use request/response HTTP when it fits; use server push or bidirectional connections only when the interaction actually needs them.

Simple protocol choices

HTTP request/response: a common choice when the interaction naturally fits request/response and does not need a persistent two-way channel.

Server-Sent Events (SSE): server-to-client event stream over HTTP when the client mainly receives updates.

WebSocket: persistent two-way channel when both sides need frequent real-time messages.

Async messaging: use when producer and consumer should be decoupled in time or load.

Evidence: S9, S17, S41, S42

Checklist

• Client-to-service and service-to-service communication paths are visible.

• Protocol choice is justified by interaction needs, not fashion.

• Every remote call has a timeout and defined failure behavior.

• TLS/authentication requirements are defined across trust boundaries.

• Persistent connections have reconnect, failover, and capacity behavior.

• Geographic latency and data location are considered where relevant.

• Payload size and serialization cost are reasonable for the path.

• Load balancer/gateway behavior is compatible with the selected protocol.

• DNS/service discovery assumptions are understood for internal services.

Evidence: S9, S17, S27, S41, S42