Messaging design patterns

In general, system messaging follows one of two messaging patterns:

• Synchronous 
• Asynchronous  

Synchronous communication is useful when the communication is one-to-one and requires an immediate response. Synchronous communication is useful in scenarios where the business logic or running a Process depends on the response or when the request fails, and the producer needs to handle the compensating actions. 

Asynchronous communication is useful for long-running services, and a Process does not require an immediate response. As a result, services are decoupled from each other to isolate and distribute the running of processes, which avoids bottlenecks of service failures and inversion of control.  

Pega Platform™ supports synchronous and asynchronous messaging patterns. By default, most of the processing happens synchronously. However, Pega Platform supports the configuration of asynchronous messaging or processing. You can achieve asynchronous processing in Pega Platform by running Rules or Processes in parallel.

Rules run in parallel by using the concept of multithread processing. For example, in Pega Platform, you can run a call to a queue processor. Then, in another thread, you can continue running some independent business logic that is available in a Data Transform or an Activity.   

Processes run in parallel by using the concept of split-for-each, split-join, and spin-off flow types. Pega Platform also supports defining parallel Processes. For example, an Onboarding Case Type might run the Processes of different departments in parallel to complete employee onboarding quickly and efficiently.

Check your knowledge with the following interaction:

As an application architect, you design systems that stay responsive under heavy load and ensure reliable processing of business logic. Messaging patterns decouple user requests from background processing so that the UI responds immediately while services process work asynchronously, at scale, and with resilience.

Review the following core messaging patterns and guidance on when to implement them in Pega Platform™.

Fire and forget pattern

Use the fire-and-forget pattern when you need immediate confirmation and can complete downstream processing later. Examples include dispute intake, order placement acknowledgments, and post-processing of file uploads.

Invoke a standard or dedicated queue processor by using the Queue-For-Processing activity or the Run in Background flow shape. The system commits the thread without waiting for downstream integrations to complete. Retries and error handling occur in the background.

Load leveling

Apply load leveling when incoming volume spikes could overwhelm databases or external systems. For example, a partner batch of one million records received at 9:00 PM daily.

Design a dedicated queue processor with tuned settings for concurrency, batch size, commit frequency, and delayed processing. Items persist on the Stream Service, and nodes consume them steadily based on node classification.

Publish/subscribe

Use the publish/subscribe pattern when a single business event needs to fan out to multiple independent consumers. For example, a “Customer address changed” event updates billing, statement generation, and Pega Customer Decision Hub™ profiles.

Configure Stream Data Sets (Kafka topics) as event channels. Data Flows subscribe to these channels and process events into target systems. Loose coupling between the publisher and subscribers lets you add or modify consumers without changing the publisher.

Scheduled polling

Use scheduled polling for time-driven processing of periodic maintenance and compliance tasks. For example, closing temporary cases older than 30 days, performing nightly reconciliations, and generating weekly rollups.

Use a job scheduler that wakes on schedule, queries the scope, performs work, and then sleeps. No per-item message is required.

Request-reply (synchronous messaging)

Use synchronous messaging when you send a request and wait for a direct response from the receiver. This pattern is required for real-time data validation, synchronous API calls, or when business logic depends on immediate feedback.

Use connectors (REST, SOAP, MQ, JMS) for synchronous calls. Implement error handling and compensating actions for failures.

Check your knowledge with the following interaction: