Every task in an application either makes the caller wait or lets the caller carry on. Choosing between synchronous and asynchronous processing is one of the most important design decisions in Pega, because it affects user experience, load and reliability.
Synchronous processing
The caller sends the request and waits for the answer before doing anything else. The user sits on the screen until it returns. Use it when the next step depends on the result.
Asynchronous processing
The caller hands the work off and continues immediately. The work runs in the background and its result arrives later, or nobody needs it. Use it when the work is slow, can fail and be retried, or does not affect the next screen.
Comparison
| Synchronous | Asynchronous | |
|---|---|---|
| Caller | Waits | Carries on |
| User experience | Screen blocked until done | Screen responds at once |
| Failure handling | Error shown straight away | Retry and report later |
| Load pattern | Spikes during busy periods | Smoothed out by a queue |
| Pega examples | A Connect-REST call whose result fills a form | Queue Processor, Job Scheduler, background steps |
A worked example
A customer applies for a credit card on a bank's website.
- Synchronous: the credit score check. The next screen depends on the score, so the application calls the bureau and waits a second or two.
- Asynchronous: the welcome email and the card-printing request. The customer does not need to wait for them, so the case queues both. If the mail server is down, the queue processor retries later.
How to choose
- Does the next step need the result? Synchronous.
- Could it take more than a few seconds, or fail often? Asynchronous.
- Would a failure be embarrassing on screen but harmless if retried? Asynchronous.
Interview tip
Define each in a sentence, then give the credit check and the welcome email as your pair of examples. Also mention retries, because that is why asynchronous work is safer. Read more in Queue Processor vs Job Scheduler.
No comments:
Post a Comment