Designing a System: How to Avoid Common Issues
Recently I wrote a blog about the role of micro-services architecture in payment gateway transactions. Unfortunately, there is a trap into which many of us fall when designing a system: we try to break micro-services up into what we know - domain knowledge. This usually results in these services becoming very reliant on one another, thereby creating nano-services.
How do we solve this issue? I’ve been looking at IDesign.net and following a Microsoft legend, Juval Löwy (http://www.idesign.net/About). The focus is primarily on the design of architecture for modern software. I am not going to repeat what has been written, but I will apply it to the design of our applications.
The advisement is to first collate the smallest building blocks to see whether they will be able to satisfy the current system as well as future requirements. The second step is to assess the design to see which services are performing an overlapping functionality. The third and final step is to combine these services into one. These core services should be able to address all of the required use cases.
The Role of Micro-services in System Communication
In my previous blog article, I spoke about having a micro-service per processor. Think about it, if you have 100 processors, that means you have 100 micro-services that need to be supported, yet in the end, all of these micro-services achieve the same thing. They call a processor and make a deposit, handle notifications and perform status checks. All of this happens via communication over HTTPS, with the use of HTTP Requests. This can be done with a service. The way this service communicates and the information that needs to be extracted for a processor can be data driven, informing the micro-service how to do calls for each processor. The HTTP communication can then be extended for different functionalities required, such as certificate management.
Another example of what can happen is that companies create small services for functionality that are very similar, and so can be grouped together into services. For example: SMS service, Email Service and other services responsible for communication. These can be grouped into a Communication service with functionality for each different way of communication.
I am not going to go into detail on how to achieve or structure your design to achieve your goals. Here is a great article on one way of how to achieve this. https://codewithspoon.com/2017/07/software-architecture/. My advice is to invest a few days up front, ensuring that the design is correct before implementing. This can save you from paying the price down the line where you cannot extend the system properly as all use cases have not been covered, or the services are so dependent on each other that it leads to major timeframes to make simple changes or to add new features. Also, analyse the functionality and make sure not to solve just the one single problem at hand but rather be able to handle future problems. Review the design with a few people; ask questions on why certain things are happening, establish which services are performing the same task and move it to one service. Lastly, do not start coding on the first prototype with the view that it will be the production system, as that will lead to lots of issues down the line.
Feeling inspired? Head over to our careers page to see if we have the perfect role for you.