How do you choose between async and sync middleware for your web app?

The existence of middleware to avoid star connectivity ( every systems connects to every systems) also give systems to adhere store and forward pattern which introduce asynchrony. To be fare everyone wants synchronous system but synchronous systems are very costly and error prone in this asynchronous world with limited resources. So the middleware manifested in this world :)

Compatibility is the basic check before installation, configuration and integration, but performance is something which can not be compromised for business applications, async will be the choice for long term goal that provides the stability and consistency .

Synchronous systems are very hardware intensive with prevalent bottleneck of input and output systems. Every software engineers encounters production slowness due to slow database (ultimately slow disk) or because of network latency. A very manifestation of these bottlenecks are stuck thread or thread is wait state because slow IO. So to optimize resources and cost and a stable systems, asynchrony helps.

This, as written, is somewhat misleading, as depending on the underlying code there's almost always a lock at some time at least when writing data in (otherwise one can get messy hardware integrity problems).

Pros : - definitely more reliable systems - runs with minimum hardwares, - system throttle in high load scenarios - with the usage of reactive and Spring async pattern or message queue threads pool has bandwidth to do other works Cons: no guarantee of request-response time, user might feels slow system responsiveness.

Additional con(s): "flooding" which can happen at many different layers; for example, the network or the hardware -- too high a throughput can throttle an async process and even lock it. "delayed critical path" execution: Since rarely does the business logic allow for complete parallelism or independent execution some critical (and single point) paths may get delayed causing both performance and execution errors especially "propagation" errors.

Pros: - System response time is predictable. - System implementation is simple. - Cons: - high usage of resources, cpu, memory etc - systems does not throttle well in flood gate open scenarios - costly

En effet, avec ce type de Middleware communément appelé MOM (Middleware Orienté Message) il existe deux modèles d'application très pratiques selon la communication et la diffusion des messages : 1-le modèle Queue en file d'attente selon le scénario N à 1 pour plusieurs expéditeurs vers un destinataire selon l'ordre d'arrivée et avec ou sans accusé de réception. 2-le modèle Topic de type abonnement/publication selon le scénario 1 à N ou N à N pour plusieurs consommateurs sur une ou plusieurs souscriptions. Très souvent la chose la plus importante avec ce type de Middleware est d'être exécuté sur une infrastructure puissante avec un bon niveau de QoS pour répondre entre autre aux exigences de qualités de fiabilité, robustesse et résilience.

Async middleware vs. Sync middleware for your web app depends on how much performance and scalability the app would require. In case the application has to support high concurrency, meaning many requests without blocking processes inside the application, like real-time data or I/O-heavy tasks, then your middleware should be better as an async because it unblocks the resources for other tasks and becomes efficient. Another factor is that synch middleware is much easier and performs rather well for apps with simple request-response workflows where tasks are done in sequence as opposed to requiring deep parallelism. The final judgment depends upon the trade-off between complexity, performance, and resource management.

Sync process are usually light weight and can be “moderate” weight in certain cases which depends on the actual time out configured in the system. In cloud middleware system, timeout are preconfigured with the max (I have seen is 300 seconds) whereas on-premise tool, this can be configured by the administrators. However, configuring higher timeout can prove to be costly from resource lock-in/consumption. Advocate sync if the system being built does not have dependency which has variability in response. Async is better in scenarios which has high variable factors beyond the control of the middleware (like external web service, high processing jobs (like finance)), thus avoids ripple effect in impacting system stability.

One often needs to do a cost benefit analysis and certainly must ascertain what the key data points are for both the business and program logic, what latency (if any) can be tolerated, what parts of both the business and program logic lend themselves best to (potential) parallel execution and triage for the parts where the program and business logic both agree they either benefit from or tolerate parallelism.