Messaging defines the way o5/j5 applications share data. There are three topologies available, defined below.

Applications are called Workers when they are the recipient of messages, Senders are the ... sender.

Workers expose gRPC endpoints for each group of messages they receive, and an rpc endpoint for each specific message type.

The gRPC definition for all messaging endpoints must return google.protobuf.Empty - even for Reply type queues - as no service should ever be waiting for a reply.

service FooTopic {
  option (pentops.messaging.v1.config).broadcast.topic_name = "foo";
  rpc Bar(BarMessage) returns (google.protobuf.Empty);
}

Senders fall into two broad categories: Those with databases and those without.

Any sender with a database should use the Outbox pattern, where outbound messages are stored in a table, and committed atomically with other database changes. The platform will then take messages from the outbox table and send the message through the messaging infrastructure.

Senders without databases, e.g. a translation service, or even senders which have a database but do not mutate state in message processing (e.g. a read-only lookup reply) can instead send messages to the messaging infrastrcutre using gRPC requests intercepted by the platform. The platform will expose the gRPC service as defined in the protos and foward the messages as required. The platform returns OK + Empty when the message has been safely stored in the messaging infrastructure.

• Zero or more Sender applications
• Exactly one 'Topic'
• Zero or more Worker applications

• Zero or more Sender applications
• Exactly one Worker application

• Exactly one Worker application
• Exactly one Input Queue
• Zero or more Sender applications