Geeks Tech Stack

This post intends to share my experience in defining configuration for software products that require a large number of configurations. There are applications such as message brokers, ESBs, POS systems, etc that require multiple configurations to make that product works. At this point, the user may lose in a sea of configurations if the developer does not correctly place those configurations in proper order and if documentation is completed. How could you arrange your configuration such that the user can easily work with it? There could be different things that may become reason, software to become harder to configure. Bad user experience in configuring software means your product loses customer impression. The entry point for your software application most probably maybe doing configuration. If the user thinks configuring is hard at this point, he may give up the whole product. Early days developer used simple config formats such as properties file to configure products. Property file

  Think you’re running a web service that requires input and delivers it to another backend service. If backend service is not available for some time, then what kind of fail-proof system you should implement? This is where the Circuit breaker design pattern comes in. Let’s think about a situation when a request goes to a middleware application and you need to call another remote backend service. If everything goes fine and smooth, the application can forward the request to the backend service and send the response back to the client. But, if the backend service was down, the request could not be completed. In the next few requests from the client also tries to call backend service and getting fail. Here, we can use the Circuit Breaker model to manage backend errors. According to the circuit breaker pattern, the middleware may be in the following possible states. Circuit Breaker Pattern Closed State  Just like the electronic circuits, the closed state is the operating state. Request a