How to Build a Flexible, Scalable Backend Architecture for Growing Startups

1. Overview of General Architecture

When a startup begins, developers often choose the simplest stack (e.g., LAMP, SSH) to iterate quickly. While these stacks handle early growth, they become hard to maintain as the business becomes complex, leading to massive classes, tangled if‑else logic, and difficulty onboarding new developers. Adopting a more adaptable architecture from the start can avoid many pitfalls.

2. Implementation of General Architecture

The proposed architecture evolves from the classic three‑tier model (controller → service → DAO) into a gateway layer, business layer, and foundation layer.

2.1 Gateway Layer

The gateway layer processes different network protocols such as HTTP and TCP, acting as the entry point for all external calls.

2.1.1 HTTP Requests

HTTP requests from PC or app clients are handled by containers like Tomcat and frameworks such as Spring MVC, which provide RESTful handling. Controllers are organized by business domain (e.g., order, member). Each controller method performs three tasks: parse request parameters, invoke the underlying service, and assemble the response, while logging and converting exceptions without exposing stack traces.

2.1.2 TCP Requests

TCP handling is typically built on Netty, often wrapped in custom protocols. Distributed frameworks (Dubbo, RocketMQ) also rely on TCP. The gateway abstracts whether the call originates from a single‑machine or distributed environment, parsing parameters, invoking business services, and handling exceptions uniformly.

2.1.3 Summary

The gateway layer isolates protocol handling and shields external callers from internal business changes, enabling decoupling between callers and business logic.

2.2 Business Layer

The business layer hosts the core processes and rules, structured into three sub‑layers: business services, business processes, and business components.

2.2.1 Business Service

Business services expose a unified façade composed of an interface, input parameters, and output parameters. Interfaces represent domain‑specific services (e.g., OrderService, MemberService) and can be split into read/write variants to enable read/write separation. Input models are layered: common domain objects (e.g., OrderDO, DishDO) combined with request‑specific data to form Request objects. Output models may be simple for write operations or complex composite objects for reads, allowing selective inclusion via query selectors.

2.2.2 Business Process

Business processes translate business rules into code, typically consisting of three node types: parameter assembly, rule evaluation, and action execution. For example, creating a restaurant order involves assembling a DishOrderDO, applying business rules, and invoking the DAO to persist the order. Processes should be broken into small, reusable components.

2.2.3 Business Component

Components encapsulate cohesive, reusable code fragments and correspond to the three node types above. Higher‑level abstractions called “capabilities” combine multiple components (e.g., a SMS capability consists of a parameter‑assembly component and a sending component). Over‑abstracting for fast‑changing internet scenarios is discouraged.

2.3 Foundation Layer

The foundation layer provides interface definitions and technical components.

2.3.1 Interface Definition

Interfaces are designed per technology framework but reflect business intent, following the principle of programming to interfaces. For example, DAO methods are named insertUser, updateUserById rather than generic insert/update, and cache interfaces use domain‑specific names like cacheUser.

2.3.2 Technical Components

Typical single‑machine technical components include:

Data storage : relational databases (MySQL) for most data, NoSQL (HBase) for logs or archival, and file systems (Linux FS or HDFS) for large files.

Cache : local memory caches (nanosecond), distributed memory caches (memcached – millisecond), and persistent distributed caches (Redis – hundred‑millisecond).

Messaging & scheduling : asynchronous messaging (e.g., RabbitMQ) and scheduled tasks for periodic jobs.

Transaction : database‑backed transactions, typically managed via Spring‑Tx, grouping tightly related DB operations.

Lock : optimistic locks using version fields and pessimistic locks via JDK Lock interfaces.

3. Summary

The architecture described above is a practical, generic solution that has been refined through extensive experience and can support rapidly changing business requirements.

Source: http://www.uml.org.cn/zjjs/201803062.asp