Most of the new projects start out as a single codebase where all the components interact with one another via direct function calls. However, as the user traffic and codebase increases, we will start facing issues with the codebase. Here are a few possible reasons for this:

• Your codebase is growing in size and this means that it will take longer for any new developer to understand the complete system.
• Adding a new feature will take longer because we have to make sure that the change doesn't break any of the other components.
• Redeploying code for every new feature might become cumbersome because of the following:
  • Deployment failed and/or
  • One of the redeployed components had an unexpected bug which crashed the program and/or
  • The build process may take longer because of a large number of tests
• Scaling the complete application to support a CPU intensive component

Microservices provide a solution to this by splitting up the major components of the application into separate smaller applications/services. Does this mean we should split our application from the start into microservices so that we don't face this issue? That is one possible way of approaching this subject. However, there are certain drawbacks to this approach as well:

• Too many moving parts: Dividing each component into its own service means that we will have to monitor and maintain servers for each of them.
• Increased complexity: Microservices increase the number of possible reasons for failure. Failures in a monolith may be limited to the server(s) going down or issues with code execution. However, with a microservice we have to:
  • Identify which component's server(s) went down or
  • If a component fails, identify the failing component and then further investigate whether the failure was due to:
    • Faulty code or
    • Due to failure in one of the dependant components

• Harder to debug the whole system: The increased complexity described in the preceding points makes it harder to debug the complete system.

Now that we have seen some of the pros and cons of microservices and monolith architecture, which one is better? The answer should be fairly obvious by now:

• Small to medium-sized codebases benefit from the simplicity offered by a monolith
• Large codebases benefit from the granular control offered by the microservices architecture

This means that we should design our monolith codebase with the expectation that it might eventually grow to a very large size, and then we will have to refactor it into microservices. In order to make the task of refactoring the codebase into microservices as effortless as possible, we should identify the possible components as early as possible, and implement the interaction between them and the rest of the code using the Mediator design pattern.