The Critical path method is a common step in project management. It is handy for a large or complex project because it keeps our focus and reduces the risk of project delays. Is it possible to use these project practices in software architecture?

One of the goals of every software engineering team is to provide high availability. In other words, be up how much you can. So here is the opportunity to talk about the "Critical path." So let's transform this concept into good practice.

"Critical" means “most important or sensitive step” with it in mind. In a microservice architecture, we can identify the essential services for our customers. A simple example is a search service on a classified website or payment modules in e-commerce. Those services usually are the most transactional and require our users to go online. On the other hand, services that use queues and batch processes typically aren't critical. A good example is an invoice microservice; anybody loses their mind for receiving a receipt late.

To put this into practice, you can follow these three guidelines:

Keep it absurdly simple. We must scale these good practices and brake a couple of rules it is necessary. So, use only a few services, technologies, and program languages because everything increases the risk of failure.

Last out, first priority. However, every new technology or update should start on other services, and more importantly, you must continually update your critical path services.

Fewer microservices. Microservices mesh can produce a high level of Reusability. However, this increases the number of critical services. So a microservice bigger than the average could mean reduced communications and fewer essential services for us.

In summary, identifying our critical path is a great way to reduce failure and increase availability. As a result, we can keep the focus on our most important service and create a safe way to innovate. Remember:

If everything is important, then nothing is."

― Patrick Lencioni.