Key Principles for Splitting Microservices: Keep Core Apps Independent

The author presents three practical principles for partitioning a system into microservices, distilled from repeated failures and incidents.

Principle 1 – Separate core applications. Even trivial features such as a scheduled task, a slow SQL query, or a reporting job can drag down critical services like order or payment processing. A one‑minute outage immediately draws intense operational attention, and developers feel the pressure of a “hot pan of ants.” Therefore, any functionality that could jeopardize revenue‑generating services should be extracted into its own service, especially when traffic spikes are anticipated.

Principle 2 – Prevent delivery inefficiency as team size grows. Larger teams introduce concurrent conflicts: code merges, branch divergences, test interference, and deployment collisions. Different modules naturally evolve at different paces, and without clear separation the speed and quality of feature delivery suffer. Google’s shift to microservices was driven by the need to enable many engineers to work in parallel; a monolith cannot scale with the organization.

Principle 3 – Define the microservice’s purpose. The author cites a personal example, a service named service‑resource, dedicated to handling heavyweight operations such as large file uploads and parsing big emails. Placing these resource‑intensive tasks inside the core application would risk destabilizing it, so they are isolated in a specialized microservice. The three rules together form a checklist for architects considering service decomposition.