Microservices in the Era of High Interest Rates

Recently, I had a very interesting conversation about microservices. In times of high interest rates, with a focus on engineering efficiency, choosing a microservices infrastructure is not a popular choice—and for the majority of organizations, that's a good thing. The truth is, microservices can be hard to maintain, costly, and often provide limited returns. Most companies can achieve similar outcomes with proper code splitting and a modular monolith architecture. However, at some scale—which is hard to estimate and highly dependent on the type, traffic, and regions—it becomes challenging to scale a monolith too.

Yet, I often see a huge misconception in understanding the fundamentals. Avoiding microservices doesn't mean you should not build separate applications; it simply means to carefully consider when to stick with the current one. Several factors should be considered before making a decision:

• The potential size of the project in the future
• How separate the business unit/domain is
• The frequency of information exchange between systems
• The need for data consistency
• Whether addressing some technical debt, such as moving a part of the system to a new framework or language version, is a consideration

A good example of when you may consider creating two separate systems could be the E-commerce Engine and a Product Information Management (PIM) system, or a Content Management System (CMS). I strongly recommend adapting these systems from the market rather than creating them from scratch, but that's a topic for another post. And keep it mind that as always, it all depends on the size, scale, and team, as there is no silver bullet solution. You must adjust and use your expertise to make decisions, sometimes with a touch of your "spider sense."

Even if you have some standalone, single-responsibility services like invoice generation or a CO2 emission calculator, combine them into a single application and create an aggregator app. If one service becomes a bottleneck or uses a specific resource type (e.g., heavy CPU or RAM usage), you can then abstract it and secure dedicated resources. This approach keeps the system diagram simpler, makes it easier to navigate, and simplifies monitoring and deployment.

There's also another aspect to consider: your team's motivation. Give them at least some area to explore to prevent boredom. From my experience, bored engineers perform less efficiently, their morale drops, and they become disengaged. Most talents just want to learn new things, and at some point, you should consider giving them this opportunity and the best way to do this is to release a production-grade microservice/application 😄