RPC
General
Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network's details.
A procedure call is also sometimes known as a function call or a subroutine call.
Core Features
KubeMQ supports CQRS) based flows with the following core features:
Commands - A synchronous two ways Command pattern for CQRS) types of system architecture.
Query - A synchronous two ways Query pattern for CQRS) types of system architecture.
Response - An answer for a Query type RPC call
Timeout - Timeout interval is set for each RPC call. Once no response is received within the Timeout interval, RPC call returns an error
Grouping - Load balancing of RPC calls between receivers
Caching - RPC response can be cached for future requests without the need to process again by a receiver
Commands
Commands is a synchronous two ways RPC (Request and Response) pattern for CQRS) types of system architecture.
This pattern implements the ‘Command’ part of CQRS as follows:
A Sender will submit a request to a channel with a specific Timeout for getting a Response.
A Receiver will subscribe to a Channel (and Group if needed), will receive the Sender request together with unique ‘ReplyTo’ channel address. KubeMQ generates this address.
A Responder, which can be either the Receiver service or a different service, will process the request and respond only if the Request was successful or not. in case of unsuccessful response, the responder can add an ‘Error’ description into the response message.
The Sender will get the response from the Responder.
If no response is received within the Timeout that was set by the Request, an error message will be returned (‘Timeout’).
Use Cases
Commands pattern is suitable for use cases, such as sending updates to a DB, WebHooks, or any request without the need of response by a specific time.
Queries
Queries’ is a synchronous two ways RPC (Request and Response) pattern for CQRS types of system architecture.
This pattern implements the Query part of CQRS as follows:
A Sender will send a Request to a channel with a specific set timeout for getting a Response.
A Receiver will subscribe to a Channel (and Group if needed), will receive the Sender request together with unique ‘ReplyTo’ channel address. KubeMQ generates this address.
A Responder, which can be either the Receiver service or a different service, will process the request and respond with the query results (data), along with the execution result and appropriate Error string in the event of unsuccessful query processing.
The Sender will get the response from the Responder.
If no response is received within the timeout that was set by the Request, an error will be returned (‘Timeout’).
Use Cases
Queries pattern is suitable for use cases, primarily for database queries.
Caching
KubeMQ supports caching of query results as follows:
A Sender will send a Request to a channel with a specific set timeout, Cache key (string) and Cache TTL (Time To Live) value in seconds for getting a Response.
KubeMQ will attempt to get the response results from Cache base on the Cache key.
If a Response is stored in Cache, then the sender will get the response from the Cache.
If a Response is NOT stored in Cache, KubeMQ will send the Request to an available Receiver (as above).
Once a valid response is received from a Responder, KubeMQ will store the Response in the Cache, along with the Cache key provided by the Sender, for the time set by Cache TTL.
A new Request within the Cache TTL time-frame, and with the same Cache key, will get the same Response as stored in KubeMQ from the previous Sender Request.
Commands vs. Queries
Commands and Queries are very similar patterns. However, there are two differences:
Commands Response returns only if the request is successful or not, while Query returns with data in the Response.
Queries support Caching, while Commands does not.
Last updated
