A layered decoupled deterministic idempotent identity generation method and system

Abstract

The application discloses a layered decoupling deterministic idempotent identification generation method and system. The method physically separates the session access stage and the service identification generation stage: the session access stage generates a session access certificate based on non-service attributes to prevent replay attacks; the service identification generation stage only constructs a service unique key based on service parameters and generates an idempotent handle through a deterministic algorithm; a minute boundary double window atomic query and TTL guarantee threshold checking mechanism are adopted to provide a clock drift tolerance of ±30 seconds; and offline verification capability is realized through reverse verification of the server. The application eliminates the long-term bidirectional mapping index of the service key to the identification, and the storage overhead can be reduced by more than 70%, the generation delay can be optimized to less than 1ms, and 100,000 + high-concurrency scenarios per second are supported; 100% cross-node consistency, zero-downtime configuration hot update, financial-grade security salt value rotation and cross-system offline verification capability are provided, and the application can be widely applied to distributed payment, e-commerce transaction and other scenarios.

Description

Technical Field

[0001] This application relates to the technical field of idempotency guarantee, and particularly relates to a method, system, computer-readable storage medium, and electronic device for generating a deterministic idempotent identifier with hierarchical decoupling. Background Art

[0002] In current distributed systems, to ensure the idempotency of requests (i.e., the same request produces the same result when executed multiple times), the following four types of technical solutions are mainly adopted:

[0003] (1) Two-phase identifier allocation mode (such as Stripe Idempotency-Key, AWS Lambda Powertools)

[0004] The client first sends a special meta-request to apply for a Request-ID (a randomly assigned identifier), and the server generates and returns it. Then the client carries this identifier to initiate an actual business request. The server needs to maintain a <Request-ID, result> mapping table to implement idempotent query. This mode has a logical loop of "needing an ID to obtain an ID". Existing mainstream practices all adopt the method of the server generating a random identifier and storing the mapping table: the client first applies for an Idempotency-Key, and the server stores the <Key, result> mapping. These solutions all need to maintain the mapping relationship between the business key and the random ID, and there are problems of recursive dependence (the request for applying for the Key itself needs idempotency guarantee) or storage overhead, and offline verification cannot be supported.

[0005] (2) Random generation and mapping table storage mode

[0006] The server randomly generates a Request-ID such as UUID, and at the same time maintains a mapping table of the business key (such as the order number) and the Request-ID (stored in Redis or a database) for querying the original identifier during subsequent retries. This mode needs to additionally maintain the <business key, Request-ID> mapping relationship and a reverse index query table. Due to the one-way nature of the random function, the association between the business key and the ID must be established through the mapping table, resulting in storage overhead linearly related to the number of concurrent requests and the lifetime of the mapping table.

[0007] (3) Client random generation mode

[0008] The client generates a UUID as the Request-ID, and the server only performs duplicate checking. The identifier has no association with the business parameters, and the business attribution cannot be verified. When there are duplicates or misjudgments, it cannot be traced.

[0009] (4) Authentication protocol derivation mode (OAuth 2.0 / JWT dimensionality reduction application)

[0010] Drawing on the two - stage architecture of OAuth 2.0 authorization code + access token, an idempotent identifier issuance service is designed. The client first applies for an idempotent token in JWT format, and the server returns a JWT containing the jti (JWT ID) claim; the client carries this JWT to execute a business request; the server verifies the authenticity through JWT signature and maintains a <jti, processing result> mapping table.

[0011] The above - mentioned existing technologies have the following defects and deficiencies:

[0012] (1)Recursive - dependency defect (core defect)

[0013] The two - stage scheme has a recursive paradox for homogeneous business requests: To obtain an idempotent identifier for a business request, the client must first initiate a homogeneous, business - related "pre - ID application request". If this pre - request requires idempotency guarantee, a higher - level identifier must be introduced. If such a two - stage architecture is directly applied to the idempotent scenario, since both stage one (applying for credentials) and stage two (business execution) involve business interactions, it may trigger potential recursive - dependency risks. That is, to ensure the idempotency of the pre - request, a more pre - existing identifier is needed (in this scheme, by introducing a session - admission stage with non - business attributes, this dependency chain is physically cut off at the architecture level). If the idempotency is abandoned, re - transmission caused by network jitter will cause the server to re - allocate different identifiers, directly breaking the idempotency assumption at the business layer. The OAuth 2.0 / JWT scheme is particularly typical: Its two - stage architecture (obtaining Token → accessing resources) is a homogeneous recursive structure, and both stage one and stage two are of the nature of access credentials, without achieving physical isolation between transport - layer session admission and business - layer identifier generation.

[0014] (2)Non - determinism nature and storage overhead

[0015] Based on the generation method of random strings or JWTs, it is impossible to ensure the consistency of retry identifiers for the same business request. JWTs compulsorily contain fields such as iat (issuance time) and jti (unique identifier) that are different for each request. Two retries of the same business request will generate different JWT strings, which are misjudged as new requests by the system. This non - determinism leads to the necessity of maintaining a <jti, result> mapping table, and the length of the JWT itself (200 - 500 characters) is much longer than the required length of the idempotent identifier (32 - 40 bits).

[0016] (3)Lack of verification mechanism and runtime configuration dependency

[0017] The existing identifier generation logic lacks a verifiable mechanism, and the关联性 between the identifier and the business request is weak. When performing cross - system verification, it usually requires the receiving party to access the external configuration center or service of the sending party (such as querying the Token revocation list in OAuth 2.0), which has a runtime configuration dependency and cannot meet the offline verification requirements under the zero - trust architecture.

[0018] (4) Race conditions caused by clock drift

[0019] In high-concurrency scenarios, if a time-window-based temporary token mechanism is adopted, clock drift between distributed nodes (even with NTP synchronization, there is still a 1-10 millisecond deviation) may cause two requests from the same client near the minute boundary to be assigned to different time windows, generating different temporary tokens and violating the idempotency assumption.

[0020] (5) Risks of simultaneous configuration changes

[0021] In scenarios involving the construction of business unique keys or the updating of salt values, existing technologies lack an effective versioning synchronization mechanism. The asynchrony between client and server caches can lead to inconsistent construction, which in turn can cause idempotency verification failures. Summary of the Invention

[0022] To address the aforementioned problems in the existing technology, this application proposes a novel layered decoupled deterministic idempotent identifier generation method.

[0023] In summary, the present invention adopts the following technical strategies:

[0024] (1) The recursive elimination heterogeneous layering decoupling mechanism divides idempotency guarantee into the session admission stage and the business identifier generation stage:

[0025] Session admission phase: A session admission certificate is generated based on non-business attributes (client identifier, time window) to prevent replay attacks;

[0026] Business identifier generation stage: Construct a unique business key (BUK) based solely on business parameters (including the subject identifier) ​​and generate an idempotent handle using a deterministic algorithm;

[0027] Isolation mechanism: Session access certificate information is not involved in the calculation of idempotent handle generation, physically severing recursive dependency chains.

[0028] (2) Version synchronization and boundary processing mechanism of business metadata configuration center. The business metadata configuration center realizes "one negotiation and multiple pre-configuration" of cross-system BUK construction rules. Each participant is offline synchronized and fixed locally. The BUK parameter list supports version release (such as payment@v1.1) and coexistence of multiple versions. The main identifier is a required parameter of BUK. The rejection policy for missing parameters, the sharding / selective extraction policy for overflowing parameters, and the degradation and rollback mechanism (with random suffix) when hash collision occurs.

[0029] (3) Based on the deterministic generation mechanism of BUK and fixed salt value, the business unique key (BUK) is the fundamental way to achieve deterministic generation and eliminate long-term bidirectional mapping indexes: it transforms scattered business parameters into a normalized unique string, making IH a cryptographic digest of the business parameters themselves. Determinism is expressed as the mathematical function IH = F(BUK, Salt_Version), that is, for any distributed node, the same input will necessarily output the same IH; the three-layer identification structure (session access certificate / RI / TF) and configurable truncation mechanism, RI (32-40 bits) realizes algorithm self-description and offline verification through a local built-in mapping table. The difference from conventional HMAC signatures lies in the three major constraints of input solidification, salt value versioning, and output binding.

[0030] (4) Clock drift tolerance mechanism with minute boundary fault tolerance: minute boundary dual-window query + TTL guarantee threshold (>30s) verification; ±30-second clock drift tolerance to ensure idempotency of retries across minute boundaries. The difference from the conventional sliding window is the dual-window atomic query, strong TTL threshold verification and strong client identity binding.

[0031] (5) Configure a single-write convergence and dual-path upgrade mechanism for gray release, combining regular hot update (SDK actively pulls) and forced fallback (error code trigger) to ensure 100% client eventual consistency; the gray release version conversion state machine ensures that V1 / V2 requests do not compete for the same storage key in concurrent scenarios.

[0032] (6) A progressive four-layer time-series race condition protection system with clear layered defense objectives: minute-boundary fault tolerance (clock drift) → distributed atomic operation (global barrier) → process-level lock (reduce load) → database constraint (ultimate consistency).

[0033] (7) A business status validity verification mechanism during cross-system verification. When the RI already exists, the validity of the business status is forcibly verified (instead of directly returning historical results) to ensure the correctness of the results in a distributed environment.

[0034] Specifically, this application provides the following technical solutions:

[0035] The first aspect of this application provides a layered decoupled deterministic idempotent identifier generation method, such as... Figure 1 As shown, the method includes:

[0036] S1. Business metadata configuration: Pre-configure business unique key construction rules, which include a list of business parameters defined by business type, parameter validation rules and hierarchical salt value mapping relationship, and support version management and hot update;

[0037] S2, Layered Decoupling Identifier Generation: Idempotency assurance is divided into a session admission phase and a business identifier generation phase. The session admission phase generates a session admission certificate based on non-business attributes to prevent replay attacks. The business identifier generation phase constructs a unique business key based only on business parameters and generates an idempotent handle through a deterministic algorithm. The information of the session admission certificate does not participate in the generation calculation of the idempotent handle.

[0038] S3. Deterministic Generation: Based on the business unique key and fixed salt value, an idempotent handle is generated through a deterministic algorithm. The idempotent handle is used as a routing identifier for distributed storage and routing. The same business request generates the same idempotent handle on any distributed node.

[0039] S4, Clock Drift Tolerance: Performs dual-window atomic queries at minute boundaries and combines them with TTL-guaranteed threshold checks to provide clock drift tolerance and ensure the idempotency of retry requests across minute boundaries;

[0040] S5. Verification and Storage: Perform server-side reverse verification on the generated idempotent handle. After successful verification, store the business results using the route identifier as the key.

[0041] Furthermore, in the method of this application, the construction of the business unique key in step S1 follows the following normalization rules:

[0042] The format is "Business Type: Subject Identifier: Parameter Name 1 = Value 1: Parameter Name 2 = Value 2:...";

[0043] Parameter names are sorted in ascending order of UTF-8 encoded Unicode code points;

[0044] Special characters in the value are encoded as percentages according to RFC 3986.

[0045] The main identifier is a required parameter.

[0046] Furthermore, in the method of this application, the hierarchical decoupling in step S2 includes the following three generation strategies:

[0047] Strategy A: The client locally calculates and generates an idempotent handle based on the business unique key and a fixed salt value, which is suitable for trusted environments;

[0048] Strategy B: Generated immediately after server-side pre-verification, suitable for untrusted client environments;

[0049] Strategy C: Phase 1 applies for session access certificates based on non-business attributes; Phase 2 generates formal idempotent handles based on business parameters. The session access certificate is discarded immediately after verification, and its information is not involved in the idempotent handle hash calculation. The session access certificate format includes a fixed prefix, a version prefix, a hash prefix, and a random suffix, with each part connected by a separator. The session access certificate has a lifespan of minutes. Through a minute-boundary fault tolerance mechanism, that is, simultaneously querying the current minute window and the previous adjacent minute window, the effective identification window is extended to span two minute cycles (approximately 2 minutes). Combined with the TTL guarantee threshold, clock drift tolerance is provided to cover extreme network latency and retry scenarios.

[0050] Furthermore, in the method of this application, the deterministic algorithm described in step S3 is:

[0051] IH=Base58(HMAC-SHA256(BUK,Salt));

[0052] Wherein, IH is an idempotent handle, BUK is a business unique key, and Salt is a fixed salt value. The idempotent handle satisfies the mathematical function relationship IH=F(BUK,Salt_Version).

[0053] The routing identifier is generated by truncating and optimizing the idempotent handle. The format is {version_prefix}_{truncated_hash}, and the total length is a preset simplified number of bits. The truncated hash body is obtained by truncating the complete hash value to a preset safe number of bits and then encoding it using a preset encoding method.

[0054] Furthermore, in the method of this application, step S4 includes:

[0055] First, query the current minute window: Key_Cur = temp:{client_id}:{current_minute};

[0056] If Key_Cur does not exist, then query the previous adjacent minute window Key_Prev = temp:{client_id}:{previous_minute}, and require that the remaining time to live (TTL) of the record is greater than the preset guarantee threshold.

[0057] If the remaining TTL in the previous window is less than or equal to the preset guarantee threshold, it is determined to be invalid and a new certificate is created in the current window;

[0058] The preset protection threshold is a time value sufficient to cover the maximum clock drift between distributed nodes, so as to provide a clock drift tolerance corresponding to the preset protection threshold.

[0059] Furthermore, in the method of this application, the server-side reverse verification in step S5 includes:

[0060] Extract the version prefix from the idempotent handle and query the local built-in mapping table to restore the algorithm description;

[0061] Based on the business type and configuration version identifier, obtain the corresponding business unique key construction rules from the local pre-configured configuration;

[0062] Reconstruct the business unique key based on the original business parameters and recalculate the idempotent handle for comparison;

[0063] The entire process does not access external configuration centers or services, enabling offline verification.

[0064] Furthermore, the method in this application also includes a configuration canary release step: when updating the fixed salt value, a single-write convergence strategy and a dual-path upgrade mechanism are executed. The single-write convergence strategy ensures that the storage layer uniformly uses the new version identifier as the unique key, and the dual-path upgrade mechanism includes regular hot updates and a forced fallback path to ensure 100% client eventual consistency.

[0065] Furthermore, the method of this application also includes a progressive four-layer timing race condition protection step, which is executed in the following hierarchical order:

[0066] L1 Time Layer: Minute boundary fault tolerance mechanism to intercept duplicate requests with adjacent times;

[0067] L2 Distributed Layer: Global atomic lock barrier, preventing concurrency across processes / nodes;

[0068] L3 process layer: Local lock cache, reducing the load on distributed locks;

[0069] L4 data layer: Database unique constraints ensure eventual data consistency.

[0070] Furthermore, the method in this application also includes a hash collision handling step: the server atomically checks whether there are already records with the same route identifier but different business unique keys. If a hash collision is detected, a random suffix is ​​appended to the end of the idempotent handle and it is marked as a collision degradation mode.

[0071] In step S5, if the route identifier already exists, a service status validity check is forcibly performed. After confirming that the service status is valid, the stored result is returned. If the service status has expired, the original route identifier is invalidated and the service process is re-executed.

[0072] A second aspect of this application provides a layered decoupled deterministic idempotent identifier generation system, wherein the system implements the steps of the aforementioned layered decoupled deterministic idempotent identifier generation method during operation, such as... Figure 2 As shown, this system includes:

[0073] Business metadata configuration center: used to pre-configure business unique key construction rules, which include a list of business parameters defined by business type, parameter validation rules and hierarchical salt value mapping relationship, and supports version management and hot update;

[0074] Layered decoupling identifier generation module: used to divide idempotency guarantee into session admission stage and business identifier generation stage. The session admission stage generates session admission certificate based on non-business attributes to prevent replay attacks. The business identifier generation stage only constructs a business unique key based on business parameters and generates an idempotent handle through a deterministic algorithm. The information of the session admission certificate does not participate in the generation calculation of the idempotent handle.

[0075] Deterministic generation module: used to generate idempotent handles based on business unique keys and fixed salt values ​​using a deterministic algorithm. The idempotent handles are used as routing identifiers for distributed storage and routing. The same business request generates the same idempotent handle on any distributed node.

[0076] Clock drift tolerance module: used to perform dual-window atomic queries at minute boundaries and combine TTL-guaranteed threshold verification to provide clock drift tolerance to ensure idempotency identification of retry requests across minute boundaries;

[0077] Verification and storage module: used to perform server-side reverse verification on the generated idempotent handle, and store the business results with the route identifier as the key after successful verification.

[0078] A third aspect of this application provides an electronic device, including: a memory and a processor;

[0079] Memory: Used to store computer programs;

[0080] Processor: Used to execute the computer program to implement the steps of the aforementioned layered decoupled deterministic idempotent identifier generation method.

[0081] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the aforementioned layered decoupled deterministic idempotent identifier generation method.

[0082] In summary, compared with existing solutions, the present invention has the following advantages:

[0083] (1) Eliminating recursive dependencies and long-term bidirectional mapping indexes

[0084] Introduce a non-business session admission stage (session admission certificate) through heterogeneous hierarchical decoupling, physically separate "generating business identifiers" from "establishing trusted sessions", and cut off the recursive chain; generate in a single stage through a deterministic algorithm without maintaining a long-term two-way mapping index between business keys and IHs. In typical business scenarios (tens of millions of daily active users, millions of QPS), after eliminating the long-term two-way index from business keys to Request-ID, the storage structure is reduced from O(2n) of <business key, Request-ID> + <Request-ID, result> to O(n) with only RI as the key (only retaining the short-term idempotent cache of ID → result), and the actual storage can be reduced to less than 30% of the traditional mapping table scheme; the generation latency is reduced to within 1ms (Policy A) or within 5ms (Policy C, vs 45ms for two stages), adapting to high-concurrency scenarios with more than 100,000 identifiers generated per second.

[0085] (2) Ensure identifier determinism and consistency

[0086] Based on a deterministic algorithm of BUK and fixed salt values, utilize the cryptographic hash feature to ensure that the same business request will necessarily generate the same IH; ensure the credibility of the client generation scheme through the server-side reverse verification mechanism; ensure consistency and robustness during changes through the BUK parameter list versioning mechanism (including parameter missing / overflow handling).

[0087] The business unique key (BUK) is the foundation for the deterministic generation and elimination of the long-term two-way index in this solution: it transforms scattered business parameters (including mandatory subject identifiers) into normalized and unique strings, making the identifier (IH) the cryptographic digest of the business parameters themselves rather than an unrelated random mapping. Therefore, it is possible to reverse-infer business uniqueness through IH without maintaining a long-term mapping table of <business key, ID>, achieving a strong binding between ID and business requests. The cross-node consistency of this solution reaches 100%; it supports lossless gray-scale updates of BUK rules, avoiding idempotency failures caused by configuration changes; in extreme cases, it has clear error handling or degradation strategies (such as hash conflict degradation).

[0088] (3) Support configuration hot update and business continuity

[0089] The single-write convergence mechanism is combined with a dual-path upgrade strategy (regular hot update + forced fallback) to achieve salt value无感 switching; the BUK parameter list is versioned and released and synchronizes progressively, supporting gray-scale updates. The idempotency guarantee is not interrupted during configuration hot updates, achieving zero downtime; it supports regular salt value rotation for financial-level security requirements.

[0090] (4) Achieve verifiability and cross-system interoperability

[0091] The solution employs a layered identifier design (session admission certificate / RI / TF) + server-side reverse verification; a short code prefix + a locally built-in mapping table achieves algorithm self-description and verification independence (zero runtime dependency); the RI length is compressed to 32-40 bits. Compared to traditional solutions (such as Stripe and AWS) that require a network query for each verification (introducing latency of tens to hundreds of milliseconds and the risk of single point of failure), this solution's offline verification mechanism reduces verification latency to local microsecond-level computation (e.g., < 0.1ms), and still works normally even when there is network partitioning or the sender's service is unavailable, achieving absolute reliability and efficiency in the verification process. Furthermore, this solution supports cross-organizational and cross-system offline verification (zero-trust architecture); the shortened key length reduces Redis memory usage and network transmission overhead.

[0092] (5) Eliminate race conditions caused by clock drift

[0093] A minute-boundary fault tolerance mechanism combined with TTL guarantee threshold verification provides a clock drift tolerance of ±30 seconds (far exceeding the actual distributed system deviation of <1 second). This completely eliminates the "cliff effect" at minute boundaries, ensuring that retry requests across minute boundaries are still identified as the same idempotent session. Based on the minute-boundary fault tolerance mechanism and ±30-second tolerance, theoretical calculations and experiments show that in a distributed environment with a clock deviation of <1 second, the probability of failure of the minute-boundary idempotency guarantee is less than 10%. -8 Theoretically, its reliability can reach 99.999%.

[0094] (6) Enhance cross-system state consistency

[0095] In strategy B / C, when RI already exists, a timeliness check of the business status is enforced to prevent the return of expired results and ensure eventual consistency of distributed transactions across systems. Attached Figure Description

[0096] To more clearly illustrate the technical solution of this application, the accompanying drawings involved in the description of this invention will be briefly introduced below. It should be noted that the drawings only show some embodiments of the invention. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0097] Figure 1 This is a flowchart illustrating the overall implementation of the layered decoupling deterministic idempotent identifier generation method of the present invention.

[0098] Figure 2 This is a structural diagram of the deterministic idempotent identifier generation system with layered decoupling according to the present invention.

[0099] Figure 3 This is a flowchart illustrating the overall system architecture and request processing of the present invention.

[0100] Figure 4 This is a schematic diagram comparing the recursive dependencies of the present invention and traditional solutions.

[0101] Figure 5 This is a schematic diagram of the three-layer structure of the idempotent identifier in the present invention.

[0102] Figure 6 This is a timing diagram of the minute boundary fault tolerance mechanism in the present invention.

[0103] Figure 7 This is a flowchart illustrating the configuration of canary release and version state machine transition in the scheme of this invention. Detailed Implementation

[0104] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments.

[0105] A Deterministic Idempotent Identifier Generation Method and System with Layered Decoupling

[0106] (I) Overall Architecture

[0107] This system includes a business metadata configuration center, a client generation module, a server generation module, a policy configuration module, an identifier verification module, an identifier storage module, and an exception handling module. These modules work together to achieve deterministic idempotent identifier generation without recursion or mapping tables.

[0108] Business Metadata Configuration Center: Used to pre-configure the original business parameter list, parameter validation rules, and hierarchical salt value mapping relationships required to construct a business unique key (BUK) according to business type, supporting hot updates and version management. This center realizes "one-time negotiation, multi-party pre-configuration" of BUK construction rules across systems: when deploying systems or updating versions, each participating party offline synchronizes the parameter list, validation rules, and salt value version mapping relationships of the business type through an encrypted channel and embeds them in the local SDK or configuration file; when business requests run, no online negotiation or query is required to achieve consistency of BUK construction and verifiability of idempotent handles.

[0109] Versioning and synchronization mechanism for the BUK parameter list: The business metadata configuration center supports versioned releases and gradual synchronization for changes to the BUK parameter list.

[0110] Each change generates a new configuration version (e.g., payment_v1.1);

[0111] The server and client SDKs support multiple version configurations coexisting. The version identifier in the request specifies the version of the BUK parameter list used in the current request.

[0112] When processing a request, the server uses the corresponding rules to rebuild and verify the BUK based on the version number declared in the request.

[0113] This system adopts a layered and decoupled design, with each module being a logical functional module. It can be deployed on any node of any distributed architecture (such as business service nodes, gateway nodes, and data processing nodes), without depending on a specific system deployment architecture, and is compatible with various distributed system scenarios such as microservices, SaaS, stream processing, and message queues.

[0114] This system supports three non-recursive generation strategies (Strategy A: Client-side generation; Strategy B: Server-side initial generation; Strategy C: Temporary admission isolation), and achieves the unification of session admission, routing determinism, and audit variability through a three-layer identifier structure (session admission certificate + idempotent handle + tracking fingerprint).

[0115] (II) Core Definition

[0116] 1. Business Unique Key (BUK)

[0117] A combination of parameters that can uniquely identify a business request shall be constructed in accordance with the following normalization rules:

[0118] Format: Business Type: Subject Identifier: Parameter Name 1 = Value 1: Parameter Name 2 = Value 2: ...;

[0119] Example: payment:buyer_id=10001:order_no=20250214:amount=100.00:currency=CNY (Note: Parameter names are sorted in ascending order of Unicode code points: amount < buyer_id < currency < order_no).

[0120] Namespace isolation: "Business type:" is used as a mandatory prefix to form a logical namespace;

[0121] Subject Identifier Mandatory: The subject identifier (such as buyer_id, client_id, or user_id) is a mandatory parameter to ensure that different subjects generate different BUKs for the same business parameters, avoiding cross-user conflicts; the subject identifier is usually the buyer ID, user ID, or device ID; for system-level tasks or background batch processing scenarios, the subject identifier can be a predefined system service account identifier (such as "SYSTEM" or a specific Service ID) to ensure that a unique business key can still be constructed when no natural person subject is involved.

[0122] Sorting rules: Parameter names are sorted in ascending order of UTF-8 encoded Unicode code points (e.g., 'amount' < 'user_id') to ensure consistent lexicographical order across systems;

[0123] Encoding rules: Special characters in the value (such as =, :, space, etc.) are encoded using percentages conforming to RFC 3986.

[0124] Negotiation rules for parameter selection:

[0125] Pre-configuration priority: Retrieve a list of pre-configured BUK parameters from the metadata configuration center based on the business type (biz_type), and extract only the parameters specified in the list;

[0126] Naturally unique key priority: If the business has a naturally globally unique parameter (such as refund_no), the single parameter can be directly selected as the BUK;

[0127] Combined unique key fallback: If there is no naturally unique key, select the smallest combination of parameters (which must include the main identifier) ​​to ensure that it can uniquely identify a business request;

[0128] Handling extreme situations:

[0129] Missing parameters: If the pre-configured BUK parameter (including the subject identifier) ​​is missing in the request, the client will directly report an error locally under strategy A; under strategies B / C, the server will return the PARAM_MISSING_FOR_BUK error code and refuse to process the request.

[0130] Parameter overflow: If the length of a business parameter exceeds a preset threshold (e.g., 4096 bytes), a sharded hash or selective extraction strategy should be adopted. Overflow handling rules need to be predefined in the configuration center.

[0131] Hash Collision Fallback: Although the collision probability of HMAC-SHA256 is negligible under normal business volume (collision space of 2^128), to meet the extreme rigor of financial-grade scenarios, the system has a built-in hash collision detection and degradation mechanism. When generating IH, the server atomically checks whether a record with the same RI but different BUK plaintext already exists in Redis (attaching the SHA256 fingerprint of the BUK for fast comparison); if a hash collision is detected, a two-digit Base58 random suffix (such as PAY_V1_a3fK9m_7x) is automatically appended to the end of the IH, and this generation is marked as "collision degradation mode" to ensure that even when a mathematically very low probability event occurs, the system can still correctly distinguish different business requests.

[0132] BUK is a local intermediate computation product and is not carried independently in the header / body of the network request. It is constructed on-site by the requester (strategy A) or the server (strategy B / C) based on the original business parameters.

[0133] 2. Fixed Salt

[0134] The pre-configured salt value supports hierarchical configuration combinations (configured separately by business domain, tenant, and system level), and supports versioning and time-based management (configurable 90-day / 180-day rotation cycle).

[0135] The fixed salt value is distributed to each node in the cluster and trusted clients through a secure configuration center with encrypted transmission, ensuring global / layered consistency within the same version cycle.

[0136] Salt value layered derivation formula: Key derivation is performed using HKDF (HMAC-based Extract-and-Expand KeyDerivation Function): Salt = HKDF(Salt_system, Salt_tenant ||Salt_biz, info='salt_derivation'), or by XORing two independent calculations of HMAC-SHA256, to ensure salt value isolation in a multi-tenant environment and avoid length expansion attacks.

[0137] Client-side salt value hot update mechanism:

[0138] Regular hot update (main path): The SDK detects configuration changes through long polling or timed heartbeat (e.g., every 30 seconds), automatically pulls the new version salt value to update the local cache, and subsequent new requests automatically use the new salt value to generate idempotent handles;

[0139] Forced backup (abnormal path): After the gray-scale period ends, a specific error code is returned to the unupdated clients to trigger an emergency update.

[0140] 3. Idempotency Handle (IH) and Routing Identifier (RI)

[0141] Idempotent Handle (IH): The format is {version_prefix}_{hash_body}, and the logical identifier is generated using Base58(HMAC-SHA256(BUK, Salt)). The determinism of this scheme is represented by the mathematical function: IH = F(BUK, Salt_Version). That is, for any distributed node, as long as the same business parameter (BUK) and the same salt version are input, the function F will necessarily output the same IH, achieving deterministic generation of "same input, constant output".

[0142] The fundamental difference between this solution and conventional HMAC-based signatures: Conventional HMAC-based identifiers (such as AWS Signature V4) are primarily used for request signature verification, with their core purpose being tamper prevention. Their input parameters include volatile factors such as temporary keys and timestamps, and they lack the "constant output for the same business request" characteristic required for idempotency. This solution achieves idempotency specificity through three layers of constraints: 1) Input solidification: BUK construction rules are versioned and pre-configured offline by the configuration center; 2) Salt versioning: Salt rotation is smoothly transitioned through version prefixes and a gray-scale mechanism; 3) Output binding: IH is directly used as a routing identifier, eliminating the need to maintain a mapping table from business keys to IDs.

[0143] Routing Identifier (RI): A derived identifier generated based on the hash body of the IH and the service type, serving as the physical representation of the IH in distributed storage and routing. The design of RI reflects an engineering trade-off between security, storage efficiency, and readability: by truncating the hash to 128 bits (sufficient security), the length is controlled to 32-40 bits (simplified mode: 4-8 bits for the prefix + 22 bits for the truncated hash + 4-6 bits for the optional service label), which is superior to the 36 characters of a complete UUID, while retaining the algorithm's self-descriptive prefix (ensuring verifiability), achieving the optimal solution for all three. The IH and RI algorithms share the same origin; RI optimizes storage and transmission efficiency through truncation but does not change the deterministic nature of the IH.

[0144] Bit length specification: The overall character length of RI is controlled between 32 and 40 bits (simplified mode), and configurable truncation strategies are supported.

[0145] Simplified mode (recommended): Version prefix (4-8 bits) + truncated hash body (22 bits, the first 128 bits of HMAC-SHA256 are Base58 encoded) + optional business tag (4-6 bits), total length 30-36 bits;

[0146] Full mode: version prefix (8-12 bits) + full hash body (44 bits, 256 bits Base58 encoded), total length 52-56 bits.

[0147] The truncated hash still possesses sufficient cryptographic security: the birthday attack resistance strength of a 128-bit hash is 2. 64 In the normal business volume (<10 9 The collision probability is negligible under (requests / day), and BUK provides a secondary uniqueness guarantee.

[0148] 4. Algorithm self-description and verification independence

[0149] The version prefix possesses algorithm self-description and cross-system verification independence:

[0150] Self-descriptive: The prefix (or the result of its resolution through a local mapping table) uniquely identifies the hash algorithm, salt version, and business domain context required for verification;

[0151] Verification independence (zero runtime dependency): The receiving system can independently verify the validity of the identifier by holding only a local pre-built algorithm version mapping table and the corresponding version salt value, without having to query any configuration center, database or service of the sender at runtime.

[0152] Encoding obfuscation mode (high security): Uses a 4-8 character random string (such as A7X9) as the foreign key of the system's built-in mapping table;

[0153] Layered encoding mode (highly readable): Uses 6-12 bit layered strings (e.g., PAY_V1).

[0154] 5. Trace Fingerprint (TF)

[0155] The format is {routing_identifier}{timestamp}{node_id}_{random}, which appends a timestamp, node identifier, and a 6-8 character Base58 random string to the route identifier. The total length is controlled between 55 and 70 characters and is used for auditing and full-link tracing.

[0156] 6. Session Admission Pass (SAP)

[0157] Definition: A session admission credential specific to Strategy C, distinct in nature from the Business Identifier (IH). Its forms include, but are not limited to, time window credentials and challenge-response credentials. Its core characteristic is that it is a session-layer credential unrelated to business parameters.

[0158] Essential difference:

[0159] SAP: Session credentials, which prove the legitimacy of the application, are generated based on non-business attributes (such as client_id, time_window) and are used for replay protection and rate control;

[0160] IH / RI: Business Identifier, which identifies the uniqueness of a business, is generated based on BUK, and is used for idempotent deduplication.

[0161] Formatting specification (preferred embodiment): S_{version_prefix}_{hash_prefix}_{random_suffix}

[0162] S: Fixed prefix, identifying the session access card (1 bit);

[0163] version_prefix: 4-8 digits, short code name of algorithm version (e.g., A7X9);

[0164] hash_prefix: Take the first 8 bytes (64 bits) of HMAC-SHA256(client_id+time_window, Salt), and after Base58 encoding, it is about 4-6 bits (e.g., a3fK).

[0165] random_suffix: A 4-6 bit Base58 random string (e.g., 9mP2x), obtained by encoding the first 4-6 bits of a cryptographically secure random number (4-6 bytes generated by CSPRNG) using Base58.

[0166] Complete example: S_A7X9_a3fK_9mP2x (total length approximately 16-24 characters, including separators).

[0167] Lifecycle: Minute-level, with an effective window of approximately 2 minutes achieved through a minute-boundary fault-tolerant mechanism (non-sliding window, overlapping coverage of the current minute window with the previous adjacent minute window); this is a natural overlap mechanism for dual windows, not a simple expansion of window size, and ensures the determinism of the overlap period by requiring the remaining TTL of the previous window to be greater than 30s, unaffected by clock drift.

[0168] (III) Core Technology Solution

[0169] 1. Deterministic generation strategy for recursive elimination

[0170]

[0171] Rigorous proof (formal definition) of recursive blocking of strategy C:

[0172] Let the business request be R. The traditional approach is f(R) → ID1, then g(ID1) → Result, which carries the risk of recursion.

[0173] The solution is as follows: h (non-business attribute) → SAP (session layer), then F (BUK) → IH (business layer).

[0174] Satisfy: SAP Domain(F) means that the SAP information set and the domain of the IH generation function have no intersection.

[0175] Strategy C, which eliminates recursive dependencies, focuses on stage heterogeneity and information isolation.

[0176] Phase 1 (Session Admission): As a non-business admission phase, it only verifies non-business attributes such as client identity and time window. It guarantees natural idempotency within the (client_id, time_window) dimension through distributed storage atomicity (SET NX), without generating business identifiers or relying on previous business IDs.

[0177] Phase Two (Business Identifier Generation): As a business identification phase, the IH is generated entirely based on the original business parameters (BUK). The session access certificate is discarded immediately after verification, and its information does not participate in or contribute to the IH generation process.

[0178] Dependency: Business idempotency = Session admission verification (non-business, no recursion) + BUK uniqueness (inherent to business parameters), does not constitute a recursive structure of "needing another business ID to obtain a business ID".

[0179] Heterogeneous physical isolation: Session admission credentials are transport layer session credentials (proving "who initiated the request within the specified time"), while IH (Identifier) ​​is a business layer logical identifier (proving "what kind of business this is"). The two are physically isolated in the security domain, and the credentials are destroyed immediately after verification, ensuring that their information never contaminates the generation of the business identifier. Therefore, the recursive chain is physically severed rather than logically compromised.

[0180] Compared to the recursive structure of traditional OAuth 2.0: The two-phase approach of traditional solutions (taking OAuth 2.0 as an example) is a homogeneous recursive structure:

[0181] Phase 1: Authentication request Auth(R) → Token;

[0182] Phase Two: Executing Businesses with Tokens (Biz(R))

[0183] If Phase 1 Auth(R) requires idempotency guarantees, then Auth(Auth(R)) is needed to obtain a higher-level token, forming an infinite descending chain.

[0184] The two-stage approach of strategy C in this scheme is a heterogeneous isolation structure:

[0185] Phase 1: Session admission h(client_id, time_window) → SAP;

[0186] Phase Two: Business Identifier F(BUK) → IH.

[0187] Satisfy: SAP In Domain(F), the output of Phase 1 is not used as a component of the input of Phase 2, and the recursive chain is physically severed at the architectural level. This is the essential difference between this scheme and all known two-phase architectures.

[0188] Minute boundary fault tolerance mechanism (to resolve clock drift):

[0189] When the server receives a session access permission request, it executes the following atomic query sequence:

[0190] First, query the current minute window: Key_Cur = temp:{client_id}:{current_minute};

[0191] If Key_Cur does not exist, query the previous adjacent minute window Key_Prev = temp:{client_id}:{previous_minute}, and the remaining time-to-live (TTL) of the record must be greater than the preset guarantee threshold (e.g., > 30 seconds); if the remaining TTL of Key_Prev is ≤ the preset guarantee threshold (e.g., ≤ 30 seconds), it is determined that it is insufficient to guarantee the stability of subsequent business sessions, and is regarded as an invalid record and ignored, and a new certificate is created in the current window;

[0192] If a valid record exists in any window, the existing certificate is returned; otherwise, an atomic creation (SET ... NX EX) is performed in Key_Cur.

[0193] The fundamental difference between this mechanism and a conventional sliding window: Conventional sliding windows (such as Redis rate-limited sliding logs) only address smooth statistics over time and lack the idempotent semantics required for session admission, ensuring that "the same client returns the same credentials when retrying across minute boundaries." The core innovations of this mechanism are: 1) Dual-window atomic query: Precisely queries two discrete windows, the current one minute and the previous minute, ensuring that requests near the minute boundary are accurately classified into the same session; 2) Strong TTL threshold validation: Requires the remaining TTL of the previous window to be greater than 30 seconds to be considered valid, avoiding residual interference from expired windows; 3) Strong client identity binding: Dual-window queries only apply to the same client_id, and credential generation is absolutely prohibited from carrying business parameters, ensuring the purity of the session layer is not contaminated by business states.

[0194] Quantization of clock drift tolerance:

[0195] The clock skew of distributed nodes synchronized via NTP is typically < 100ms;

[0196] This mechanism can tolerate a maximum clock drift of ±30 seconds through a TTL threshold (e.g., > 30s) and dual-window coverage (120s);

[0197] This tolerance far exceeds the clock skew of a real-world distributed system (typically < 1s), ensuring 99.99%+ reliability near the minute boundary (±1s).

[0198] Phase Two Processing Flow:

[0199] Credential validity check: Verify whether the session access card was applied for by the current client_id, whether it is within the validity period (minute boundary fault tolerance mechanism), and whether the remaining TTL is > 30 seconds; if the verification fails, return the "credential invalid" error code directly;

[0200] Credential Discarding and IH Generation: Once the verification is successful, the credential is immediately discarded. Its information does not participate in any hash calculation. Only the BUK is constructed based on the original business parameters carried by the client, and a formal IH is generated.

[0201] Subsequent processing: Perform distributed atomic operations and other idempotency guarantee procedures.

[0202] 2. Three-layer structure of the signage

[0203] SAP (Session Access Certificate): 16-24 digits, session credential, minute-level lifespan;

[0204] RI (Routing Identifier): 32-40 bits, never changes, used for distributed routing and storing key-value pairs;

[0205] TF (Tracking Fingerprint): 55-70 bits, including timestamp, node identifier, and random string, used for auditing and tracing.

[0206] 3. Four-layer protection mechanism for time-series competition

[0207] To address concurrent request conflicts in high-concurrency scenarios, a progressive four-layer defense system is established:

[0208]

[0209] 4. Configure canary release and single-write convergence mechanism

[0210] When the policy configuration center updates the fixed salt value (e.g., upgrading from Salt_V1 to Salt_V2), the system executes a lossless canary release process:

[0211] Gray-scale period setting: The system enters a gray-scale period (usually adjustable from 24 to 720 hours), where the old and new versions coexist;

[0212] Single-write convergence strategy:

[0213] The storage layer uniformly uses V2 ID as the unique key;

[0214] V2 Request: Directly calculate V2 IH;

[0215] V1 request: Use Salt_V1 to calculate V1 IH for validity verification; use the same business parameters to calculate V2 IH; use only V2 IH to query storage;

[0216] Atomic switching and hierarchical upgrade:

[0217] Regular hot updates: The SDK automatically retrieves the V2 salt value via heartbeat;

[0218] Forced fallback: After the gray-scale period ends, if the V1 request returns IDEMPOTENT_SALT_VERSION_EXPIRED, the SDK will immediately forcefully pull the new version salt value and retry.

[0219] Gray-scale state machine transition: In the Nth hour of the gray-scale period, the system maintains a version transition state machine:

[0220] V1_Request → [V1 verification passed] → V2_ID generation → [V2 storage key query] → Business processing.

[0221] This state machine ensures that in concurrent scenarios, requests V1 and V2 will not compete for the same storage key.

[0222] 5. Server-side reverse verification mechanism

[0223] The server constructs a BUK based on the business parameters explicitly carried in the request, following the same rules, and recalculates the expected IH using the corresponding salt value and algorithm for comparison.

[0224] Specific steps:

[0225] Parse version prefix: Extract the prefix from IH / RI and query the local built-in mapping table to restore the complete algorithm description;

[0226] Retrieve salt value: Retrieve the corresponding salt value from the local cache based on the restored salt_ver;

[0227] BUK Reconstruction Verification: Based on the business type and configuration version identifier, retrieve the corresponding version's BUK parameter list, extract parameters from the original business parameters to reconstruct the BUK; if pre-configured parameters (including the main identifier) ​​are missing, return the PARAM_MISSING_FOR_BUK error code;

[0228] Recalculate IH and compare it with the value provided by the client.

[0229] The entire process does not require access to the sender's external configuration center or services, achieving true offline verification capabilities. (iv) Specific implementation methods

[0231] Example 1: Strategy A (Client Generation - Trusted Environment) and Configuration Hot Update

[0232] Before initiating a payment request, the client collects business parameters such as order number, user ID (main identifier), amount, and currency, constructs a BUK payment:buyer_id=10001:amount=100.00:currency=CNY:order_no=202501010001, calculates the hash value using the HMAC-SHA256 algorithm and Salt_V1, base58 encodes it, and appends the prefix PAY_V1 to generate a simplified mode IH / RI: PAY_V1_a3fK9mP2xQm (approximately 32 bits in total length).

[0233] The client sends a request with the IH header. After receiving the request, the server parses the prefix using a local mapping table, independently reconstructs and verifies the BUK. Once the match is confirmed, the payment is deducted, and the result is stored in Redis (Key is RI, Value contains TF, TTL is set to 24 hours).

[0234] Note: This solution eliminates long-term bidirectional mapping indexes from business keys to IDs (such as the index from order number to Request-ID), not idempotent result caches (short-term caches from ID to Result, with TTL typically in the minutes range). The latter is necessary storage for idempotency, while the former is a redundant structure eliminated by this solution through deterministic generation.

[0235] Salt value hot update scenario: When the system enters a 720-hour gray-scale period, the SDK automatically pulls the V2 salt value within a 30-second heartbeat cycle; when old clients continue to use V1, the server first verifies the validity of V1 and then converts it to V2 storage; after the gray-scale period ends, an error code is returned for requests to the remaining V1 to trigger a forced update.

[0236] Example 2: Strategy B (Server-generated - Untrusted Environment) and Cross-system Verification

[0237] In scenarios where the client cannot reliably generate IDs (such as with open APIs), the client directly sends a request with business parameters. The server first verifies the validity of the parameters (e.g., the inventory quantity is a positive integer and contains buyer_id), and calculates IH and RI immediately after the verification passes.

[0238] Key logic: Check if the RI exists in Redis:

[0239] If not: Perform a business status check (such as inventory adequacy), and if the check passes, deduct the inventory and store the result;

[0240] If it exists: a business status validity check must be performed (such as checking whether the inventory has been deducted by the request or whether the order has been cancelled). After confirming that the status is valid, the stored result is returned. If the business status has expired (such as the inventory has been released), the original RI is invalidated and the business process is re-executed.

[0241] Cross-system verification scenario: An e-commerce platform transmits an order to the logistics system, carrying the IH (Indicator Number) A7X9_a3fK9mP2xQmL. The logistics system extracts the prefix A7X9 from the IH, queries its local pre-built mapping table to restore it to PAYMENT_HMAC_SHA256_V1, retrieves Salt_PAY_V1 from its local cache, constructs a BUK based on business parameters, and independently calculates the IH for comparison. The entire process requires no access to the e-commerce platform's configuration center. Even if the IH exists, the logistics system still needs to verify the local order status (e.g., whether it has been shipped) to avoid returning expired results.

[0242] Example 3: Strategy C (Temporary Admission - High-Security Environment) and Minute Boundary Fault Tolerance

[0243] For untrusted external clients, strategy C is adopted:

[0244] Phase 1: At 12:29:59.900, the client requests a session access certificate. The server creates temp:client01:1229 in Redis and returns S_A7X9_a3fK_9mP2x (total length 16 bits).

[0245] The client retried due to network jitter and requested again at 12:30:00.200 (crossing the minute boundary). The server, through the minute boundary fault tolerance mechanism, found that temp:client01:1229 was still valid (TTL>30s) and returned the same certificate.

[0246] Phase Two: The client carries the credentials (X-Admission-Pass: S_A7X9_a3fK_9mP2x) in the HTTP Header, includes complete business parameters in the request body, and passes the business type (X-Biz-Type: payment) and configuration version in the Header to initiate a business request. The server first verifies the validity of the credentials. If the verification is successful, the credentials are immediately discarded (deleted from Redis or marked as invalid). Based on the business type and configuration version identifier carried in the request, the server retrieves the corresponding BUK parameter list construction rules from the local pre-built SDK cache. Then, the server extracts the required parameters from the original business parameters in the request body to construct the BUK, generates the formal IH (such as PAY_V2_x9Lm...) and TF, and processes the business. Subsequent retries carry the IH instead of the admission credential.

[0247] It is emphasized that the BUK parameter list is obtained entirely based on local pre-configuration, without the need to query any external services at runtime, ensuring that the offline verification feature with zero runtime dependencies is continuously met.

[0248] Example 4: Configuring Canary Release

[0249] The system needs to update the BUK parameter list for payment transactions from version V1 (parameters: amount, currency, order_no) to version V2 (adding a user_id field). The configuration center will release the payment_v2.0 configuration, and the SDK will gradually pull and update it.

[0250] During the gray-scale testing phase: 30% of clients used V2, and 70% used V1;

[0251] Server-side processing: When a V1 request is received, the server uses the V1 rules to validate and calculate the V1 IH, and simultaneously calculates the V2 IH (adding user_id) as the storage key; when a V2 request is received, the server directly calculates the V2 IH.

[0252] Convergence period: After 72 hours, the server rejects the V1 request and forces an upgrade.

[0253] Example 5: Cross-domain offline verification (zero-trust scenario)

[0254] Within the medical data space, Hospital A transmits patient datasets to Research Institution B, carrying IH X7K2_a4M... (a high-security obfuscation mode prefix). Institution B's local system:

[0255] Extract the prefix X7K2, look up the local HSM (Hardware Security Module) built-in mapping table, and resolve it to MEDICAL_SM3_V3;

[0256] Retrieve Salt_Med_V3 (offline preset) from the local keystore;

[0257] Construct a BUK based on business parameters such as patient ID (main identifier) ​​and dataset hash;

[0258] Independent IH alignment was calculated to verify that the data had not been tampered with;

[0259] The entire process does not require connection to Hospital A's configuration center or database, meeting the data ownership requirements in a physically isolated environment.

[0260] Example 6: Performance Comparison Test

[0261] Test environment: 10-node Redis cluster, target throughput of 100,000 TPS, simulating a weak network environment (network retransmission rate of 10%, fault injection test).

[0262]

[0263] Key conclusions:

[0264] Latency: Two-stage mode requires 45ms due to 2 RTTs + table lookup; Strategy C requires less than 5ms for a single interaction; Strategy A requires less than 1ms for pure local computation.

[0265] Storage Model Analysis: Traditional solutions require storing two sets of data simultaneously: the mapping from the business key to the random ID and the mapping from the random ID to the result, resulting in a storage complexity of O(2n). This solution eliminates the first mapping because the ID can be deterministically reconstructed from the business key, retaining only the second, thus reducing the storage complexity to O(n). Based on typical key-value pair sizes, the theoretical storage overhead can be reduced by 50%-70%.

[0266] Correctness: UUID mode generates 10% duplicate processing at a 10% retransmission rate, while the proposed solution achieves zero duplicates; based on a minute-boundary fault tolerance mechanism and a ±30-second tolerance, theoretical calculations and experiments show that in a distributed environment with a clock skew of <1 second, the probability of failure of the minute-boundary idempotency guarantee is less than 10%. -8 Theoretically, its reliability can reach 99.999%.

[0267] Example 7: Synergistic Integration with Existing Certification Systems

[0268] This solution provides complementary, layered protection to existing authentication protocols such as OAuth 2.0, SAML, and OIDC.

[0269] Lower layer (authentication protocol): resolves whether the requester's identity is trustworthy;

[0270] Upper layer (this solution): Resolves whether "business requests are duplicated".

[0271] Typical process:

[0272] The client obtains an Access Token through the authentication protocol process;

[0273] The client uses strategy A of this scheme to generate an idempotent handle IH based on business parameters;

[0274] The client carries both the Access Token (Authorization header) and the idempotency handle (X-Idempotency-Handle header) in the business request.

[0275] The server first verifies the Access Token (identity is trusted), and then verifies the IH (whether the business is duplicated). The two are verified independently and have no cross-dependency.

[0276] Key difference: Authentication tokens can be different for each request (refresh / rotate), while IH tokens must be the same for the same business request (deterministic). They are upstream and downstream entities, not substitutes, forming a complete protection system of "authentication + idempotency".

[0277] Figure 3 This is a flowchart illustrating the overall system architecture and request processing of the present invention. The diagram shows the interaction relationships between seven major modules, including the business metadata configuration center, the client-side generation module, and the server-side generation module, and marks the data flow of the three generation paths: strategy A, B, and C.

[0278] Figure 4 This diagram illustrates the recursive dependency comparison between the present invention's solution and traditional solutions. Left side: Homogeneous recursive structure (infinite descending chain) of the traditional two-phase solution (OAuth 2.0 / Stripe); Right side: Heterogeneous isolation structure of strategy C in this solution (physical separation of SAP and IH).

[0279] Figure 5 This is a schematic diagram of the three-layer structure of the idempotent identifier in the present invention. The diagram illustrates the hierarchical relationship, lifecycle, and length specifications of SAP (Session Admission Certificate), RI (Routing Identifier), and TF (Tracking Fingerprint).

[0280] Figure 6 This is a timing diagram of the minute boundary fault tolerance mechanism in the present invention. The diagram shows the dual-window query logic (Key_Cur → Key_Prev → atomic creation) at the minute boundary, with TTL threshold verification (>30s) and clock drift tolerance (±30 seconds) marked.

[0281] Figure 7 This diagram illustrates the configuration of canary releases and version state machine transitions in the present invention. The diagram shows the canary release state machine transition process (V1_Request → V1 verification → V2_ID generation → V2 storage query), and marks both regular hot updates and forced fallback paths.

[0282] Embodiments of this application also disclose an electronic device, including: a processor, a communication interface, a memory for storing a processor-executable computer program, and a communication bus. The processor, communication interface, and memory communicate with each other via the communication bus. The processor executes the executable computer program to implement the steps of the aforementioned layered decoupled deterministic idempotent identifier generation method.

[0283] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the various steps of the layered decoupled deterministic idempotent identifier generation method disclosed in this application.

[0284] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program includes program code for executing the layered decoupling deterministic idempotent identifier generation method disclosed in this application. When this computer program is executed by a processing system, it can achieve the functions defined in the embodiments of this application.

[0285] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0286] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for generating a deterministic idempotent identifier through hierarchical decoupling, characterized in that, The method includes: S1. Business metadata configuration: Pre-configure business unique key construction rules, which include a list of business parameters defined by business type, parameter validation rules and hierarchical salt value mapping relationship, and support version management and hot update; S2, Layered Decoupling Identifier Generation: Idempotency assurance is divided into a session admission phase and a business identifier generation phase. The session admission phase generates a session admission certificate based on non-business attributes to prevent replay attacks. The business identifier generation phase constructs a unique business key based only on business parameters and generates an idempotent handle through a deterministic algorithm. The information of the session admission certificate does not participate in the generation calculation of the idempotent handle. S3. Deterministic Generation: Based on the business unique key and fixed salt value, an idempotent handle is generated through a deterministic algorithm. The idempotent handle is used as a routing identifier for distributed storage and routing. The same business request generates the same idempotent handle on any distributed node. S4, Clock Drift Tolerance: Performs dual-window atomic queries at minute boundaries and combines them with TTL-guaranteed threshold checks to provide clock drift tolerance and ensure the idempotency of retry requests across minute boundaries; S5. Verification and Storage: Perform server-side reverse verification on the generated idempotent handle. After successful verification, store the business results using the route identifier as the key.

2. The method according to claim 1, characterized in that, The construction of the business unique key in step S1 follows the following normalization rules: The format is "Business Type: Subject Identifier: Parameter Name 1 = Value 1: Parameter Name 2 = Value 2:..."; Parameter names are sorted in ascending order of UTF-8 encoded Unicode code points; Special characters in the value are encoded as percentages according to RFC 3986. The main identifier is a required parameter.

3. The method according to claim 1, characterized in that, The hierarchical decoupling described in step S2 includes the following three generation strategies: Strategy A: The client locally calculates and generates an idempotent handle based on the business unique key and a fixed salt value, which is suitable for trusted environments; Strategy B: Generated immediately after server-side pre-verification, suitable for untrusted client environments; Strategy C: Phase 1 applies for session access certificates based on non-business attributes; Phase 2 generates formal idempotent handles based on business parameters. The session access certificate is discarded immediately after verification, and its information is not involved in the idempotent handle hash calculation. The session access certificate format includes a fixed prefix, a version prefix, a hash prefix, and a random suffix, with each part connected by a separator. The session access certificate has a lifespan of minutes. Through a minute-boundary fault tolerance mechanism, that is, simultaneously querying the current minute window and the previous adjacent minute window, the effective identification window is extended to span two minute cycles. Combined with the TTL guarantee threshold, clock drift tolerance is provided to cover extreme network latency and retry scenarios.

4. The method according to claim 1, characterized in that, The deterministic algorithm described in step S3 is as follows: IH=Base58(HMAC-SHA256(BUK,Salt)); Wherein, IH is an idempotent handle, BUK is a business unique key, and Salt is a fixed salt value. The idempotent handle satisfies the mathematical function relationship IH=F(BUK,Salt_Version). The routing identifier is generated by truncating and optimizing the idempotent handle. The format is {version_prefix}_{truncated_hash}, and the total length is a preset simplified number of bits. The truncated hash body is obtained by truncating the complete hash value to a preset safe number of bits and then encoding it using a preset encoding method.

5. The method according to claim 1, characterized in that, Step S4 includes: First, query the current minute window: Key_Cur = temp:{client_id}:{current_minute}; If Key_Cur does not exist, then query the previous adjacent minute window Key_Prev = temp:{client_id}:{previous_minute}, and require that the remaining time to live (TTL) of the record is greater than the preset guarantee threshold. If the remaining TTL in the previous window is less than or equal to the preset guarantee threshold, it is determined to be invalid and a new certificate is created in the current window; The preset protection threshold is a time value sufficient to cover the maximum clock drift between distributed nodes, so as to provide a clock drift tolerance corresponding to the preset protection threshold.

6. The method according to claim 1, characterized in that, The server-side reverse verification in step S5 includes: Extract the version prefix from the idempotent handle and query the local built-in mapping table to restore the algorithm description; Based on the business type and configuration version identifier, obtain the corresponding business unique key construction rules from the local pre-configured configuration; Reconstruct the business unique key based on the original business parameters and recalculate the idempotent handle for comparison; The entire process does not access external configuration centers or services, enabling offline verification.

7. The method according to claim 1, characterized in that, The method also includes configuring a canary release step: when updating a fixed salt value, a single-write convergence strategy and a dual-path upgrade mechanism are executed. The single-write convergence strategy ensures that the storage layer uniformly uses the new version identifier as a unique key. The dual-path upgrade mechanism includes regular hot updates and a forced fallback path to ensure 100% client eventual consistency.

8. The method according to claim 1, characterized in that, The method also includes a progressive four-layer timing race condition protection step, which is executed in the following hierarchical order: L1 Time Layer: Minute boundary fault tolerance mechanism to intercept duplicate requests with adjacent times; L2 Distributed Layer: Global atomic lock barrier, preventing concurrency across processes / nodes; L3 process layer: Local lock cache, reducing the load on distributed locks; L4 data layer: Database unique constraints ensure eventual data consistency.

9. The method according to claim 1, characterized in that, The method also includes a hash collision handling step: the server atomically checks whether there are records with the same route identifier but different business unique keys. If a hash collision is detected, a random suffix is ​​appended to the end of the idempotent handle and it is marked as a collision degradation mode. In step S5, if the route identifier already exists, a service status validity check is forcibly performed. After confirming that the service status is valid, the stored result is returned. If the service status has expired, the original route identifier is invalidated and the service process is re-executed.

10. A layered decoupled deterministic idempotent identifier generation system, characterized in that, The system implements the deterministic idempotent identifier generation method of layered decoupling as described in any one of claims 1-9 during operation, and the system includes: Business metadata configuration center: used to pre-configure business unique key construction rules, which include a list of business parameters defined by business type, parameter validation rules and hierarchical salt value mapping relationship, and supports version management and hot update; Layered decoupling identifier generation module: used to divide idempotency guarantee into session admission stage and business identifier generation stage. The session admission stage generates session admission certificate based on non-business attributes to prevent replay attacks. The business identifier generation stage only constructs a business unique key based on business parameters and generates an idempotent handle through a deterministic algorithm. The information of the session admission certificate does not participate in the generation calculation of the idempotent handle. Deterministic generation module: used to generate idempotent handles based on business unique keys and fixed salt values ​​using a deterministic algorithm. The idempotent handles are used as routing identifiers for distributed storage and routing. The same business request generates the same idempotent handle on any distributed node. Clock drift tolerance module: used to perform dual-window atomic queries at minute boundaries and combine TTL-guaranteed threshold verification to provide clock drift tolerance to ensure idempotency identification of retry requests across minute boundaries; Verification and storage module: used to perform server-side reverse verification on the generated idempotent handle, and store the business results with the route identifier as the key after successful verification.

Images