High performance and availability are always hard to achieve, and microservice architecture is no exception. In the microservices world, every user request sent to a frontend application triggers a cascade of remote calls. The frontend application calls API facades, API facades ask backend services, backend services communicate with databases and even more backend services. Statistics work against you. Latencies add up but failure probabilities combine by multiplication. The more services are engaged in a flow, the more threats for performance and availability.
This article is a part of CQK Top 10 series. Many developers add cache to their application without measuring its performance impact. We are advising here that each application cache should have a very good reason to exists.
Microservices are now the mainstream approach for scalable systems architecture. There is little controversy when we are talking about designing backend services. Well-behaved backend microservice should cover one BoundedContext and communicate over the REST API. Things get complicated when we need to use microservices as building blocks for a frontend solution. How to build a consistent website or a mobile app using tens or sometimes hundreds of microservices?
The story begins two years ago during an excellent TDD training given by Szczepan Faber and Tomek Kaczanowski for a bunch of Allegro developers. Surprisingly, it was a trigger to revolutionize our builds at Allegro.
There are two parts of this article. In first we define what is Capacity (maximum load) and Resilience (fault tolerance) of a typical e-commerce site.
JDD conference is behind us. We had a great time doing a github dev contest (Chief Troublemaker Officer) for conference attendees. Some guys complained that the contest was too hard, good to hear! It was out intention not to make it too trivial.
If you are going to be in Kraków for JDD conference, October, 13-14th, don’t miss a perfect opportunity to meet our Allegro engineers!