Designing a Scalable Backend Architecture with API Layer and BFF for a Supply‑Chain System

The author, a senior architect, presents a case study of a complex supply‑chain system that includes dozens of services (product, order, store, work‑order, etc.) and multiple client apps (customer app, employee/partner app).

Two main issues are identified: (1) uncertainty about which service should host a given API, leading to inefficient decision‑making, and (2) excessive inter‑service dependencies caused by many operations needing to modify data across several services.

To address these, an API layer is introduced, responsible for aggregation, distributed calls, and data decoration. The API layer has no own database and simply forwards requests to backend services via Feign.

Client‑specific adaptation problems are then discussed. Different front‑ends (App, H5, PC, mini‑program) have varying data needs, causing the API layer to become a compatibility bottleneck. The solution is to adopt the BFF (Backend for Front) pattern, creating separate API services per client, allowing tailored optimizations and independent release cycles.

The overall technical stack is based on Spring Cloud (Zuul gateway, Spring Web API services, and backend services with their own databases). The gateway handles routing, authentication, monitoring, and rate‑limiting, while the API services perform aggregation and orchestration.

Code duplication between API services is tackled in three ways: sharing common code via a JAR, extracting a CommonAPI service, or accepting duplication when the cost of abstraction outweighs benefits. The team ultimately keeps simple proxy APIs for low‑cost cases.

Team division is clarified: a dedicated API development team maintains the API services, while backend services are split into domain‑focused groups, ensuring clear responsibilities and better overall system understanding.

Images illustrating the architecture, API layer, BFF setup, and service dependencies are included throughout the article.