Half-Sync Half-Async architectural pattern

-

Synchronous application - 

Creating synchronous services is easy for developers, as they follow a single execution path. Debugging is also easy, as developers know the execution flow by seeing the code. Creating only synchronous services is not good (primarily if your OS and HW supports event-driven architecture, it is okay if you have an embedded system with limited space and no multi-threading environment), as it is slow and time-consuming, synchronous way of execution slow down your application. 

Asynchronous application - 

Creating a fully asynchronous system is not always possible. Though they are fast and efficient. But hard to develop, especially when the user is actively involved/interacting with your application. It is challenging to create asynchronous, high-level (or say user level) APIs. But asynchronous way speed up the execution and your application become faster if you develop an excellent asynchronous model.

Mix of synchronous and asynchronous  - 

half-sync and half-sync pattern suggests to create a system, a mix of asynchronous, and synchronous system.

 Half-Sync half-Async architectural pattern give us idea, how we can develop application, which is not as complicated as asynchronous system, but it leverages the efficiency of asynchronous system by implementing most of low-level service through it. And not slow as a synchronous system, but leverages the simplicity of synchronous systems, by making high-level APIs synchronous.

How it works?

Divide the services into two parts. Run the synchronous service in a separate thread. Create a queue between synchronous and asynchronous services and communicate through queuing the requests. 

 It follows the layer pattern. Mostly high-level services fall under synchronous way of execution, and down the line, internal or low-level services through asynchronous way of execution.

Example

To be added.

 Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post clean...
Read more

Factory method design pattern for beginners.

-
Image
Background - First, let me ask a simple question. Do you really think that "factory method design pattern comes because we had an issue with creating objects? Or it is only for creating objects? Or why we need a factory to create an object when we can create it through constructor? The answer is NO! Each class is capable of creating objects on its own. Through constructor (until and unless you have not put constructor in private).  Then why we need factory at all? Is there something like, without Factory method, I am not able to create my software? No, we can create objects without it, then why we are using it very extensively? Remember one thing, programming languages are very powerful . W e can build software without following any design principles. But then, it will be poor in some of these areas -  Maintainability. Extend-ability. Performance. Security. Robust. and many more... Developers have been developing...
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one...
Read more