Backend Architecture Refactoring and Design for Consumer Installment Service

1. Background

1.2 Business Restructuring and Merging

Due to continuous demand iteration, the ZhiZhi consumer installment business underwent restructuring and introduced a new product direction, requiring a new architecture to support future business.

1.2 Solving Technical Debt

Key problems identified:

Weak module boundaries; need module and service splitting to define business boundaries.

Monolithic code lacking layered design; existing micro‑service split was based on product dimensions without extracting core services, leading to duplicated code and high maintenance cost.

1.3 Impact on Development Efficiency

Even with sufficient project knowledge, issue tracing remains time‑consuming because of tangled call chains, prompting the need for a new solution.

1.4 Inadequate Monitoring System

The online exception mechanism is not sensitive enough and lacks a key‑business alert dashboard.

2. Refactoring Goals

Do not affect normal business operation and iteration.

Improve code structure for easier extension and higher development efficiency.

Gradually replace old interfaces with new projects and deprecate the legacy system.

3. Design

3.1 Research

Investigated generic internet consumer finance architecture solutions and adopted a layered design concept for core module decomposition.

3.2 Planning

The refactor is split into two iterations: the first focuses on backend module separation and redesign; the second aligns the new backend with the frontend.

3.3 "Repairer" Mode

During the first iteration, legacy edge logic is isolated while core code is refactored into a new project that gradually takes over old logic via RPC. The second iteration connects the new backend with the new frontend, completing V2 launch.

3.4 Domain Design (Horizontal Splitting)

Modules are divided into:

Aggregation business – provides unified interfaces for frontend and checkout.

Basic services – handles user credit data and partner data.

Third‑party integration – implements standard APIs and flexible partner connections.

3.5 Module Design (Vertical Splitting)

The installment purchase flow is decomposed into independent modules such as credit acquisition, usage, and bill repayment, each adhering to single‑responsibility and dependency‑inversion principles.

3.6 Code Design

Refactoring leverages design patterns (template, strategy, factory) to separate partner‑specific logic from core services. Key interfaces and abstract classes are defined as follows:

/**
 * 授信接口定义
 */
public interface ICreditService {
    /**
     * appId，资方定义的一个唯一ID
     */
    String getAppId();
    /**
     * app名称
     * @return zz or zlj
     */
    String getAppName();
    /**
     * 获取授信结果
     * @return result
     */
    CreditResult creditResult(String logStr, Long uid);
}

/**
 * 标准API对接实现
 */
public abstract class AbstractCreditService implements ICreditService {
    protected abstract IBaseApiService getApiThirdService();
    @Override
    public AppConfig getPartner() {
        return commonConfigUtil.getAppConfig(getAppId());
    }
    @Override
    public CreditResult creditResult(String logStr, Long uid) {
        CreditResultInput input = new CreditResultInput();
        input.setUid(uid);
        ResponseProtocol<CreditResultOutput> output = getApiThirdService().creditResult(logStr, input);
        String creditStatus = TransformUtil.approvalStatusTransform(output.getData());
        return CreditResult.builder().result(creditStatus).build();
    }
}

/**
 * 标准API对接
 */
public interface IBaseApiService {
    /**
     * 标准API，获取appId
     * @return appId
     */
    String getAppId();
    /**
     * 获取授信结果
     */
    ResponseProtocol<CreditResultOutput> creditResult(CreditResultInput input);
}

/**
 * 合作方，标准API对接实现
 */
public abstract class AbstractBaseApiService implements IBaseApiService {
    @Override
    public ResponseProtocol<CreditResultOutput> creditResult(CreditResultInput input) {
        // 通用加解密
        return getDataResponse(logStr, getAppConf().getUrl4CreditResult(), input, CreditResultOutput.class);
    }
}

/**
 * ABC合作方接口封装
 */
public interface IABCThirdService extends IBaseApiService {
    String getAppId();
    ResponseProtocol<ABCCreditResultOutput> creditResult(ABCCreditResultInput input);
}

4. Deployment Process

The migration uses a one‑way data sync with gradual deprecation of the old system; rollback procedures prioritize service stability during gray releases.

5. Monitoring

Adopted ZhiZhi alert mechanism and Prometheus for online monitoring, complemented by a dashboard for early detection of module issues. Logging is emphasized as a primary troubleshooting tool.

6. Summary

The refactor eliminated technical debt, improved system stability, user experience, and delivery efficiency. It also produced a reusable, portable architecture that can serve as a “wheel” for similar financial services.