Distributed application patterns

Choose a pattern by the failure you need to handle, not by the number of annotations it uses. Every pattern below explains its use case, the J7M realization, annotated and explicit entry points, configuration and observable failure boundary.

Application need	Pattern
Find instances and replace a failed dependency	Discovery and refresh
Invoke a service or retain one exact object	Request–reply
Let a remote service call the caller	Callbacks
Compose work without confusing timeout with exit	Async and cancellation
Bound producers, consumers and buffers	Streaming and backpressure
Select available instances safely	Availability and failover
Recognize repeated business commands	Durable deduplication
Distribute recoverable work	Durable queues
Investigate poison messages	Dead letters
Coordinate message handling with SQL	Inbox and outbox
Maintain a projection from durable events	Event subscriptions
Route deterministic state updates by key	Partitioned state
Reject work from stale owners	Leases and fencing
Recover long work from a checkpoint	Durable jobs
Run persistent timed occurrences	Persistent schedules
Coordinate compensatable business steps	Sagas
Choose an actual atomicity boundary	Transactions

Read every comparison in context

An annotated handler is ordinary application code hosted through generated metadata. Its explicit counterpart exposes the operations that the host adapter otherwise owns. The two columns are not claims that the smallest fragment independently implements a full production host.

Start from the runnable applications, then follow each page's practical flow and recovery decisions. Install the named trusted host profiles before deploying annotated handlers. Do not copy development security settings into a deployed host.