Distributed lending system

Abstract

The application relates to the field of financial services and distributed technologies, and provides a distributed loan system, which comprises: a plurality of loan processing microservices, which are respectively used for executing different business links in a loan application process, the loan processing microservices are independently deployed and communicate through a network; a loan state registration center, the loan state registration center takes a loan application identifier as a key and stores a global state snapshot of a corresponding loan, the global state snapshot comprises a loan user identifier and a state field related to local decision and associated with the loan user identifier; a plurality of the loan processing microservices comprise a plurality of key loan processing microservices, and each key loan processing microservice internally integrates a local snapshot module and a consistency checker. The application realizes the consideration of safety and high performance of a loan business.

Description

Technical Field

[0001] This application relates to the fields of financial services and distributed computing technology, and in particular to a distributed lending system. Background Technology

[0002] Existing loan systems commonly employ a microservices architecture for horizontal scaling and agile development. In a typical distributed loan system, a loan application requires processing by multiple independently deployed microservices, either once or in parallel, such as anti-fraud services, credit assessment services, credit limit approval services, and loan disbursement services. Each microservice has its own database and business logic, communicating via lightweight network protocols, forming a loosely coupled distributed processing pipeline. Under this architecture, the complete state of each loan is actually scattered across the local data stores of multiple services, lacking a real-time, unified state view. To coordinate the process, some systems introduce a central process engine or event bus, driving subsequent steps by publishing state change events. However, these solutions still fail to address a fundamental problem: the state upon which a microservice bases its decisions may be modified by other concurrent operations during its processing, leading to business errors. For example, when a microservice (such as the credit limit approval service) begins processing a loan, it reads the currently known loan state (e.g., the user's remaining available credit limit) and executes business rules accordingly. However, within the millisecond window of its computation and persistence results, another concurrent loan application may have already been processed, consuming the user's entire credit limit. Because there are no global locks or strong transaction isolation in a distributed environment, the credit limit approval service cannot detect this change and will still approve the loan based on the expired state, leading to the risk of over-lending. While distributed transactions can address this issue, their complex compensation logic and coordination overhead significantly reduce system throughput and response speed in high-concurrency scenarios. Therefore, the challenge lies in addressing both the problem of the state upon which the decision is based potentially being modified by other concurrent operations during processing, causing business errors, and the issue of existing methods severely reducing system throughput and response speed in high-concurrency scenarios. Summary of the Invention

[0003] In view of the above-mentioned technical problems, the purpose of this application is to provide a distributed lending system that aims to solve the aforementioned technical problems.

[0004] In a first aspect, embodiments of this application provide a distributed lending system, the system comprising:

[0005] Multiple loan processing microservices are used to execute different business steps in the loan application process. Each loan processing microservice is deployed independently and communicates with the network.

[0006] A loan status registry center stores a global status snapshot of the corresponding loan using the loan application identifier as the key. The global status snapshot includes the loan user identifier and status fields related to local decision-making associated with the loan user identifier.

[0007] The multiple loan processing microservices include multiple key loan processing microservices, each of which integrates the following:

[0008] The local snapshot module is used to read and freeze a global state snapshot of the current loan from the loan status registry before the microservice starts executing business logic, forming a read-only local decision snapshot;

[0009] The consistency checker is used to reread the latest global state snapshot from the loan status registry after the microservice completes its business logic and persists the results, and before sending the downstream service request message. It then compares the state fields related to local decision-making associated with the target loan user in the latest global state snapshot with the corresponding state fields in the local decision snapshot.

[0010] If any comparison result is inconsistent, the consistency checker will trigger a risk interception mechanism, terminate the current loan process, and output an alarm message.

[0011] Furthermore, the multiple loan processing microservices include anti-fraud service, credit limit approval service, contract signing service, and loan disbursement service. The key loan processing microservices include credit limit approval service and loan disbursement service. For the credit limit approval service, the status fields related to local decision-making include the user's used credit limit. For the loan disbursement service, the status fields related to local decision-making include the user's used credit limit and the user's account status.

[0012] Furthermore, the risk interception mechanism includes: recording logs including local decision snapshots, the latest global state snapshots, loan identifiers, user identifiers, service nodes, and timestamps, and sending alarm events to the risk control monitoring platform.

[0013] Furthermore, after the step of comparing the state field related to local decision-making associated with the target loan user in the latest global state snapshot with the corresponding state field in the local decision snapshot, the method further includes:

[0014] If the comparison results are consistent, the microservice writes its own processing result to the loan status registry center and updates the global status snapshot of the loan.

[0015] Furthermore, the loan status registry is deployed in an in-memory database.

[0016] Furthermore, the system also includes a message broker service; after the consistency checker triggers the risk interception mechanism, terminates the current loan process, and outputs alarm information, the method further includes:

[0017] The critical loan processing microservice sends a process termination event message to the message broker service.

[0018] The message broker service notifies all other loan processing microservices involved in the loan application of the process termination event, so that the corresponding loan processing microservices can perform the corresponding state rollback or cleanup operations.

[0019] Furthermore, the system also includes an asynchronous compensation processor; when the consistency checker triggers the risk interception mechanism, the asynchronous compensation processor is activated to automatically retry or route loan applications that are intercepted due to inconsistent states to a specific queue for manual review, according to preset rules.

[0020] The distributed lending system provided in this application includes multiple loan processing microservices, each used to execute different business stages in the loan application process. Each loan processing microservice is deployed independently and communicates via a network. A loan status registry center stores a global status snapshot of the corresponding loan, using the loan application identifier as the key. The global status snapshot includes a loan user identifier and status fields associated with the loan user identifier and related to local decision-making. Among the multiple loan processing microservices are multiple key loan processing microservices. Each key loan processing microservice integrates: a local snapshot module, used to read and freeze the current loan's global status snapshot from the loan status registry center before the microservice begins executing business logic, forming a read-only local decision snapshot; and a consistency checker, used to reread the latest global status snapshot from the loan status registry center after the microservice completes its business logic and persists the results, but before sending downstream service request messages. The checker compares the status fields associated with the target loan user and related to local decision-making in the latest global status snapshot with the corresponding status fields in the local decision snapshot. If the comparison results are inconsistent, the consistency checker triggers a risk interception mechanism, terminating the current loan process and outputting an alarm message. This invention effectively solves the problem of business errors such as over-lending caused by concurrent requests in the existing microservice architecture by introducing a loan status registration center and configuring a local snapshot module and consistency checker in key loan processing microservices (such as credit limit approval service and loan disbursement service). Compared with relying on distributed transactions, which introduces high latency, reduces system throughput, and easily becomes a performance bottleneck in high-concurrency scenarios, this invention only reads a global state snapshot once at key decision points for local judgment. After the local operation is completed, it checks whether the core fields in the snapshot have been concurrently modified. If a change occurs, the process is actively terminated. Thus, it achieves effective protection against high-risk operations with extremely low additional overhead (only adding one read-only query). Under the high concurrency pressure of tens of thousands of TPS (Transactions Per Second), the system can still maintain millisecond-level response and linear scalability. It avoids the risk of over-lending and solves the problems of decreased throughput and increased latency caused by traditional strong consistency solutions, achieving a balance between security and high performance. Attached Figure Description

[0021] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the structure of the distributed lending system provided in the embodiments of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] Those skilled in the art will understand that, unless explicitly stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in the specification of this application means the presence of features, integers, steps, operations, elements, modules, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, modules, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any modules and all combinations of one or more associated listed items.

[0025] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0026] Please see Figure 1 This application provides a distributed lending system, the method of which includes:

[0027] Multiple loan processing microservices 1 are used to execute different business steps in the loan application process. Each loan processing microservice is deployed independently and communicates with the network.

[0028] Loan Status Registry 2, which stores a global status snapshot of the corresponding loan using the loan application identifier as the key. The global status snapshot includes the loan user identifier and status fields related to local decision-making associated with the loan user identifier.

[0029] The multiple loan processing microservices include multiple key loan processing microservices 11 and general loan processing microservices 12, and each key loan processing microservice integrates:

[0030] The local snapshot module 111 is used to read and freeze a global state snapshot of the current loan from the loan status registry before the microservice starts executing business logic, forming a read-only local decision snapshot.

[0031] The consistency checker 112 is used to reread the latest global state snapshot from the loan state registry after the microservice completes its business logic and persists the results, and before sending the downstream service request message, and compare the state field related to local decision associated with the target loan user in the latest global state snapshot with the corresponding state field in the local decision snapshot.

[0032] If any comparison result is inconsistent, the consistency checker will trigger a risk interception mechanism, terminate the current loan process, and output an alarm message.

[0033] In the embodiments of this application, loan processing microservices refer to multiple small, single-responsibility services in the loan business, such as anti-fraud services, credit limit approval services, contract signing services, and loan disbursement services.

[0034] The loan status registry is a centralized, high-performance in-memory store used to record the latest consensus state of each loan. A global state snapshot provides a source of facts visible to all services, avoiding the limitations caused by each service only seeing its own database. Key loan processing microservices are those that, when executing local business decisions, rely on user-level global state fields that are easily modified concurrently, and whose decisions based on expired states would directly lead to business errors (such as over-lending or lending to abnormal accounts). The state fields related to local decisions are a set of fields dynamically determined according to service responsibilities. This application's consistency check only focuses on whether adverse changes have occurred after the decision; other fields can be safely ignored. In this embodiment, it should be noted that the microservice's completion of business logic and persistence of results does not include a final commit to the global state (such as the cumulative credit limit used), but only the persistence of local decision records, i.e., writing to the microservice's own local database, and not updating the loan status registry. The multiple loan processing microservices include multiple key loan processing microservices. For example, two out of four loan processing microservices are key loan processing microservices.

[0035] In one embodiment, the loan processing microservices include anti-fraud services, credit limit approval services, contract signing services, and loan disbursement services. It should be understood that the anti-fraud service is used to identify whether a loan application involves fraudulent activity; the credit limit approval service determines whether to approve the loan and the loanable amount; the contract signing service generates electronic loan contracts and guides the user to complete a legally valid signature; and the loan disbursement service executes the actual fund transfer after all preconditions are met. Key loan processing microservices include credit limit approval services and loan disbursement services. For the credit limit approval service, its local decision-related status fields include the user's used credit limit. For the loan disbursement service, its local decision-related status fields include the user's used credit limit and the user's account status. The user account status refers to the current operational status of the main account or credit account associated with the user in the loan system, used to identify whether the user is qualified to continue financial transactions, such as normal, frozen, canceled, and blacklisted. Each microservice can only update its corresponding global state snapshot after successfully persisting its processing results to the local database and undergoing consistency verification.

[0036] To facilitate understanding of this invention, a simple example is provided below:

[0037] Assumption:

[0038] User A has a total credit line of 100,000 yuan, of which 80,000 yuan has already been used. User A submits two independent loan applications concurrently within a time window Δt: Loan Application The application amount is 15,000 yuan;

[0039] Loan application The application amount is 15,000 yuan.

[0040] The system comprises three independently deployed microservices: anti-fraud service, credit limit approval service, and loan disbursement service, as well as a centralized loan status registry. The following uses... Taking the processing flow in the quota approval service as an example, we can illustrate the specific implementation of the above-mentioned distributed system.

[0041] exist After completing the anti-fraud verification, the anti-fraud service writes a record to the loan status registry center, with the key being the loan application identifier. The value is structured data containing the current process stage ("Anti-fraud Service"), the decision results of each microservice (the Anti-fraud Service returns "Pass"), a timestamp, the user identifier, and status fields associated with the user identifier related to local decisions. At this point, the loan status registry center contains information about... A global state snapshot reflects the system's state at that moment. Consensus status: Anti-fraud measures have been passed; User A's cumulative credit limit is 80,000 yuan (this is the status field related to local decision-making in this example), timestamp: .

[0042] Subsequently, when When the anti-fraud process is completed and the credit limit approval stage begins, the credit limit approval service is processing... After confirming approval, the global status related to user A in the loan status registry will be updated, enabling subsequent approvals. The read operation may obtain data containing... The latest snapshot of credit limit occupancy information.

[0043] When the credit limit approval service receives When processing requests, before performing any business judgments, its internal local snapshot module first sends a read request to the loan status registry center to obtain the key " This is a snapshot of the current global state. The snapshot includes: the process stage is "Anti-fraud Service," user A's cumulative used credit limit is 80,000 yuan, and the timestamp is [time stamp missing]. .

[0044] The local snapshot module stores this snapshot in memory as an immutable read-only object and uses it as the sole state criterion for the execution of this business logic. Subsequent availability assessments are based on this frozen snapshot.

[0045] Credit limit approval service completed After the credit limit is verified, "Approved" will be issued. The result of "pre-allocating a quota of 15,000 yuan" is written to its local database and the transaction is successfully committed. The consistency checker is triggered before sending downstream service request messages.

[0046] The verifier revisits the loan status registry to " " is the key to read the latest global state snapshot. If The credit limit approval was completed during this period, and User A's cumulative usage limit was updated to 95,000 yuan. Upon rereading the returned snapshot, the cumulative used credit limit field value is 95,000 yuan, and the timestamp is [time stamp missing]. ( ).

[0047] The verifier compares this latest snapshot with the frozen local decision snapshot field by field and finds that the "cumulative used credit limit" field has changed from 80,000 yuan to 95,000 yuan, which is considered to be inconsistent.

[0048] The consistency checker immediately aborts upon detecting a state inconsistency. The subsequent processing flow is as follows: no requests are sent to downstream services, and no fund transfer operations are triggered. Simultaneously, the system records structured logs, including local decision snapshots, the latest global state snapshot, loan identifiers, user identifiers, service nodes, and timestamps, and sends an alarm event to the risk control monitoring platform, indicating "process aborted due to global state change."

[0049] The loan application status is marked as "verification failed - status conflict", and the user can receive a "approval not approved" response, but no financial loss occurs.

[0050] This invention effectively solves the problem of business errors such as over-lending caused by concurrent requests in the existing microservice architecture by introducing a loan status registration center and configuring a local snapshot module and consistency checker in key loan processing microservices (such as credit limit approval service and loan disbursement service). Compared with relying on distributed transactions, which introduces high latency, reduces system throughput, and easily becomes a performance bottleneck in high-concurrency scenarios, this invention only reads a global state snapshot once at key decision points for local judgment. After the local operation is completed, it checks whether the core fields in the snapshot have been concurrently modified. If a change occurs, the process is actively terminated. Thus, it achieves effective protection against high-risk operations with extremely low additional overhead (only adding one read-only query). Under the high concurrency pressure of tens of thousands of TPS (Transactions Per Second), the system can still maintain millisecond-level response and linear scalability. It avoids the risk of over-lending and solves the problems of decreased throughput and increased latency caused by traditional strong consistency solutions, achieving a balance between security and high performance.

[0051] In one embodiment, after the step of comparing the state field related to the target loan user in the latest global state snapshot with the corresponding state field in the local decision snapshot, the method further includes:

[0052] If the comparison results are consistent, the microservice writes its own processing result to the loan status registry center and updates the global status snapshot of the loan.

[0053] In this embodiment of the application, if the comparison results are consistent, the microservice writes its own processing result into the loan status registration center and updates the global status snapshot of the loan, which can ensure that the global status snapshot is updated accurately.

[0054] In one embodiment, the loan status registry is deployed in an in-memory database.

[0055] In this embodiment, it should be noted that the in-memory database provides microsecond-level read / write latency, which can meet the real-time requirements of each loan processing microservice for frequently accessing global state snapshots before and after business execution. Secondly, the loan approval process is extremely sensitive to the timeliness of state consistency verification. If a disk-based database is used, I / O latency will lead to an excessively long verification window, making it impossible to effectively intercept concurrent conflicts. Furthermore, the in-memory database supports high throughput and atomic operations (such as conditional updates), facilitating the implementation of a version-controlled snapshot update mechanism, thereby ensuring the security of state changes without relying on distributed transactions.

[0056] In one embodiment, the system further includes a message broker service; after the consistency checker triggers the risk interception mechanism, terminates the current loan process, and outputs alarm information, the method further includes:

[0057] The critical loan processing microservice sends a process termination event message to the message broker service.

[0058] The message broker service notifies all other loan processing microservices involved in the loan application of the process termination event, so that the corresponding loan processing microservices can perform the corresponding state rollback or cleanup operations.

[0059] In this embodiment of the application, by introducing an event-driven collaborative notification mechanism at the risk interception point, the problems of global state inconsistency and resource leakage caused by local failures in the distributed lending system are solved, thereby achieving more efficient resource management and stronger system self-healing capabilities.

[0060] In one embodiment, the system further includes an asynchronous compensation processor; when the consistency checker triggers the risk interception mechanism, the asynchronous compensation processor is activated to automatically retry or route loan applications that are intercepted due to inconsistent states to a specific queue for manual review, according to preset rules.

[0061] In this embodiment, when the consistency checker triggers the risk interception mechanism, the asynchronous compensation processor starts and automatically retryes or routes loan applications that are intercepted due to inconsistent states to a specific queue for manual review according to preset rules, thereby achieving a synergistic improvement in security, efficiency and experience.

[0062] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0063] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0064] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A distributed lending system, characterized in that, The system includes: Multiple loan processing microservices are used to execute different business steps in the loan application process. Each loan processing microservice is deployed independently and communicates with the network. A loan status registry center stores a global status snapshot of the corresponding loan using the loan application identifier as the key. The global status snapshot includes the loan user identifier and status fields related to local decision-making associated with the loan user identifier. The multiple loan processing microservices include multiple key loan processing microservices, each of which integrates the following: The local snapshot module is used to read and freeze a global state snapshot of the current loan from the loan status registry before the microservice starts executing business logic, forming a read-only local decision snapshot; The consistency checker is used to reread the latest global state snapshot from the loan status registry after the microservice completes its business logic and persists the results, and before sending the downstream service request message. It then compares the state fields related to local decision-making associated with the target loan user in the latest global state snapshot with the corresponding state fields in the local decision snapshot. If any comparison result is inconsistent, the consistency checker will trigger a risk interception mechanism, terminate the current loan process, and output an alarm message.

2. The distributed lending system according to claim 1, characterized in that, The multiple loan processing microservices include anti-fraud service, credit limit approval service, contract signing service, and loan disbursement service. The key loan processing microservices include credit limit approval service and loan disbursement service. For the credit limit approval service, the status fields related to local decision-making include the user's used credit limit. For the loan disbursement service, the status fields related to local decision-making include the user's used credit limit and the user's account status.

3. The distributed lending system according to claim 1, characterized in that, The risk interception mechanism includes: recording logs including local decision snapshots, the latest global status snapshots, loan identifiers, user identifiers, service nodes, and timestamps, and sending alarm events to the risk control monitoring platform.

4. The distributed lending system according to claim 1, characterized in that, After the step of comparing the state field related to local decision-making associated with the target loan user in the latest global state snapshot with the corresponding state field in the local decision snapshot, the method further includes: If the comparison results are consistent, the microservice writes its own processing result to the loan status registry center and updates the global status snapshot of the loan.

5. The distributed lending system according to claim 1, characterized in that, The loan status registration center is deployed in an in-memory database.

6. The distributed lending system according to claim 1, characterized in that, The system also includes a message broker service; After the consistency checker triggers the risk interception mechanism, terminates the current loan process, and outputs an alarm message, the method further includes: The critical loan processing microservice sends a process termination event message to the message broker service. The message broker service notifies all other loan processing microservices involved in the loan application of the process termination event, so that the corresponding loan processing microservices can perform the corresponding state rollback or cleanup operations.

7. The distributed lending system according to claim 1, characterized in that, The system also includes an asynchronous compensation processor; when the consistency checker triggers the risk interception mechanism, the asynchronous compensation processor is activated to automatically retry or route loan applications that are intercepted due to inconsistent states to a specific queue for manual review, according to preset rules.

Images