From One Server to Multi‑Version Scaling: Yirendai’s Backend Architecture Journey

V 1.0

The initial architecture was extremely simple: one front‑end server, one back‑end server, and a single database, with the front‑end deployed in a multi‑level manner.

V 1.5

Problems of V1.0

After a period of growth, user volume increased dramatically, causing the application server and database to become bottlenecks.

The team expanded, and all developers worked on the same system, leading to severe merge conflicts.

To quickly relieve pressure, a major refactor was undertaken.

Improvement measures

Front‑end optimization: browser caching, compressed transmission, and YSlow‑based page tuning.

Added CDN, static content generation, and reverse proxy.

Built a large‑scale web‑server cluster.

Vertical business splitting (e.g., separate back‑ends for APP, Web, credit review, crawling, activities, reporting, etc.).

Database changed to a master‑slave topology (one master, multiple slaves).

V 2.0

Problems of V1.5

Rapid growth pushed user count over one million, with the database still the main bottleneck.

Although the team was reasonably divided, all services still shared a single database, causing design and modification conflicts.

Heavy cache usage introduced consistency and staleness issues (e.g., a product could not be taken offline promptly because of cached data).

Improvement measures

Optimize query efficiency and shorten transaction times; operations identified the slowest online queries and tuned them.

Code optimization to improve execution efficiency.

Address concurrency problems (e.g., a user logged in on two clients simultaneously could trigger duplicate actions).

Distinguish strong consistency from eventual consistency; use cache and read‑write separation wisely.

After the improvements, performance rose markedly, but the larger system made log‑based troubleshooting harder, prompting the introduction of a dedicated logging system.

Logs from business systems were collected into a Kafka queue and visualized with Kibana and a custom tool, making log search much easier.

Logging rules

Uniformly use slf4j + logback for log output.

Ensure log correlation across systems.

Apply AOP to inject additional parameters into remote calls, enabling end‑to‑end traceability.

Log content must include: timestamp (millisecond precision), request UUID, user session, device ID, client‑side timestamp, local IP, client IP, real user IP, and the number of system hops.

V 3.0

V2.0 solved short‑term performance issues, but long‑term scalability required extensive service decomposition.

Two dimensions of splitting

(1) Basic service splitting

Basic services are categorized as non‑business‑oriented and business‑oriented.

Non‑business services have little interaction with other systems.

Business services have limited coupling, similar to primary‑key/foreign‑key relationships.

(2) Business service splitting

The company’s clear business structure allowed a natural division into two major systems: loan business and wealth‑management business.

The loan side was further split into back‑end, Web, and partner‑channel services, each containing a basic service layer (e.g., application processing and after‑sale service).

A particular challenge arose with the “matching” and “bond” services that could not be cleanly separated; these were extracted into a dedicated functional service.