How to Achieve Lightweight Process‑Level Service Isolation in a Distributed Microservice System

Background: Growing System Complexity

Our team manages a distributed microservice architecture that has expanded rapidly across multiple business lines. As the business grows, the number of business processes, functional modules, database tables, and monitoring requirements increase, leading to resource contention and stability risks during peak traffic.

Problem Statement

Within a single container, numerous services (RESTful, JSF, MQ, scheduled jobs) share CPU and memory. Under high load, the whole process can become unresponsive, causing long response times and degraded user experience.

Proposed Solutions

Solution 1 – Application Splitting

Divide the monolithic application by business or technical domain (e.g., separate apps for inventory counting, change, transfer, replenishment). Split corresponding databases into logical or physical instances, and modularize code so that only required modules are compiled for each deployment.

Solution 2 – Hystrix Isolation

Use Hystrix to provide in‑process isolation via two mechanisms:

Thread‑pool isolation: Assign each downstream service its own thread pool, preventing a single service failure from exhausting all threads.

Semaphore isolation: Limit concurrent calls with a semaphore threshold, suitable for short‑lived, high‑concurrency operations such as cache reads.

Solution 3 – Lightweight Process‑Level Service Isolation (Chosen)

Without splitting applications or adding Hystrix, create deployment‑level groups (e.g., separate groups for counting, replenishment, change) that are isolated across multiple data‑center zones. Shared code and databases remain unchanged, but each group runs in its own container instance, achieving inter‑process isolation.

Implementation Details

Isolation Deployment Groups

Define configuration sets that allow groups to share common settings while maintaining independent runtime parameters. Deploy each group to multiple data‑center zones for high availability.

Domain‑Based NGINX Routing

Split upstream definitions and route requests to different domains based on RESTful paths, creating distinct NP (namespace) domains for each business unit.

JSF Service Alias Isolation

Use alias-based routing so callers do not need to change code; adjust thread‑pool sizes and rate‑limit thresholds for each isolated JSF instance.

MQ Topic Isolation

In the YAML configuration, retain only the topics relevant to a specific business group and set all others to NONE, ensuring message traffic is confined to its domain.

Results

The lightweight process‑level isolation was deployed across inventory and warehouse services, with each unit running in dual‑zone high‑availability groups. This reduced the blast radius of failures, improved response times during large promotions, and simplified operational management.

Future Evolution

As the system continues to evolve, further domain‑driven decomposition will be applied to both business and service layers, keeping the architecture healthy and sustainable.

Illustrations