Method and system for fault switching in dual-active configurations

Abstract

In a described embodiment, a method for detecting faults is provided. The method further includes obtaining an external service list and obtaining a pre-set detection period. A fault in an external service is detected by monitoring the external service list based on the pre-set detection period. Fault information associated with the faulty external service is stored. A storage time as a duration longer than the pre-set detection period is set. An identifier is assigned to the faulty external service and a working status of the faulty external service is determined based on the assigned identifier. Accessing the external service via a first application component in a first data centre or the external service via a second application component in a second data centre is determined based on the determined working status.

Description

[0001] Method and System for Fault Switching in Dual-Active Configurations

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to distributed computing systems, and in particular to methods and systems for fault switching in dual-active configurations to manage faults in external service providers.

[0004] BACKGROUND

[0005] In modern distributed computing environments, organizations increasingly rely on complex systems that integrate numerous external interface services to deliver comprehensive solutions. These third-party service providers often provide critical functionalities such as payment processing, authentication, data feeds, or specialized computations that are more efficient to outsource than to develop in-house. To ensure high availability and reliability of these systems, many organizations employ dual-active configurations in their data centre architectures.

[0006] Dual-active configurations, also known as active-active setups, represent a resource-efficient approach to computer disaster recovery and high availability. In this configuration, two or more data centres operate simultaneously, all actively handling user services. These data centres serve as real-time backups for each other, ensuring continuous operation even if one or more data centres experiences issues. Each data centre typically includes network components for inter-centre communication, storage components for data management, computing resources for processing requests, application components for user services, and load balancing mechanisms to distribute workloads efficiently across all active data centres.

[0007] While dual-active configurations offer advantages in terms of redundancy and load distribution, they present unique challenges when managing faults, particularly those related to external interface services. Traditional fault management in dual-active systems often relies on switching all traffic from one data centre to another in the event of a failure. However, this method is often inefficient, as it may lead to unnecessary traffic redirection, potentially causing cascading failures or further issues in the backup data centre. Such massive re-routing can strain resources across data centres, lack the necessary granularity for addressing specific faults, and may result in service interruptions or degraded performance, disrupting critical operations.

[0008] Moreover, existing fault detection and management systems often lack the sophistication to handle the complexities introduced by numerous external interface services, failing to provide adequate mechanisms for quickly identifying, isolating, and addressing service-specific faults without impacting the entire system. These systems often rely on directly switching data centres or performing an overall switch for external interface services, which can lead to excessive switching and potential risks. Moreover, traditional solutions lack the granularity to handle interface-level service failures intelligently.

[0009] Therefore, it is desirable to provide a system and method that optimizes fault switching in dualactive configurations to address the disadvantages or limitations of the existing technologies or, at the very least, provide the public with a useful alternative.

[0010] SUMMARY

[0011] The present disclosure provides a system and method for managing faults in external services at the interface level. Importantly, each external service may have multiple specific interfaces or endpoints for different functions. The embodiments described herein allow for intelligent switching of individual interfaces rather than entire external services, providing a more granular and efficient approach to fault management in dual-active configurations.

[0012] In accordance with a first aspect of the present disclosure, a system for managing faults in a distributed computing environment. The system includes a first data centre and a second data centre configured in a dual-active arrangement, wherein each of the first and second data centres include: a network module configured to facilitate synchronisation and transmission between the first data centre and the second data centre; a database module; an application module configured to host software applications that interact with the external services; a load balance module configured to distribute workload; and a computing resources module configured to obtain an external service list, obtain a pre-set detection period, detect a fault corresponding to a specific interface of a faulty external service, store fault information associated with the specific interface, assign an identifier to the specific interface, and obtain a working status based on the assigned identifier.

[0013] In an embodiment, the computing resources module includes a fault detection module configured to monitor a status of a plurality of specific interfaces of the external services.

[0014] In an embodiment, the computing resources module is configured to generate the identifier by encoding at least one of a service category, a specific interface identifier, an interface type, a fault type, or a unique incident number associated with the specific interface

[0015] In an embodiment, the computing resources module includes a fault detection module configured to monitor a status of the specific interfaces of external services and a working status determination module configured to analyse the stored fault information and determine the working status of the specific interface corresponding to the faulty external service. In an embodiment, the computing resources module includes an interface switching module configured to initiate a local interface switch to redirect access for a specific faulty interface of an external service from the first data centre to the second data centre.

[0016] In an embodiment, the computing resources module includes a timing system module configured to track a storage timing associated with the stored fault information and compare the storage timing to a predetermined storage duration to determine a persistence of the fault in the faulty external service.

[0017] According to a second aspect of the present disclosure, a method for detecting faults is provided. The method for detecting faults includes: obtaining an external service list; obtaining a pre-set detection period; detecting a fault in an external service by monitoring the external service list based on the pre-set detection period; storing fault information associated with the faulty external service; setting a storage time as a duration longer than the pre-set detection period; assigning an identifier to the faulty external service; determining a working status of the faulty external service based on the assigned identifier; and determining whether to access the external service via a first application component in a first data centre or the external service via a second application component in a second data centre based on the determined working status.

[0018] In an embodiment, the first data centre and the second data centre are configured in a dualactive arrangement and synchronize the fault information via a bidirectional communication channel.

[0019] In an embodiment, the external service list includes a plurality of external services and a plurality of specific interfaces associated with each external service.

[0020] In an embodiment, the method for detecting faults further includes receiving, via the first application component, a first service response from the external service when accessing the external service via the first data centre; and receiving, via the second application component, a second service response from the external service when accessing the external service via the second data centre.

[0021] According to a third aspect of the present disclosure, a method for managing faults is provided. The method for managing faults includes detecting a fault in an external service by monitoring an external service list; storing fault information associated with a faulty external service in a database in response to detecting the fault; traversing the database for an existing fault entry corresponding to the faulty external service; updating a first storage duration associated with the existing fault entry to a second storage duration in response to identifying an existing faulty entry; initiating a timing system to obtain a storage timing; comparing the storage timing to the second storage duration; and updating a working status of the faulty external service to normal in response to the storage timing being equal to the second storage duration.

[0022] In an embodiment, the method for managing faults further includes setting the first storage duration associated with the fault information to a predetermined value in response to identifying no existing fault entry corresponding to the faulty external service and comparing the storage timing to the first storage duration.

[0023] In an embodiment, the method for managing faults further includes assigning an identifier to the faulty external service after updating the working status of the faulty external service to normal.

[0024] In an embodiment, the first storage duration is set based on a type of the faulty external service or a nature of the fault.

[0025] In an embodiment, the second storage duration is determined based on at least one of a frequency of fault occurrence, an impact on system performance, or a predefined policy.

[0026] According to a fourth aspect of the present disclosure, a method for detecting fault in a distributed computing environment is provided. The method includes initiating, via a first data centre, a status check of a specific interface associated with an external service; receiving, via the first data centre, an interface status from the external service; storing, via the first data centre, fault information associated with the specific interface; assigning, via the first data centre, an identifier to the specific interface in response to the interface status indicating a fault; transmitting, via the first data centre, the fault information and the identifier to a second data centre; determining, via the first data centre, a working status of the specific interface based on the identifier; accessing, via the first data centre, the specific interface of the external service in response to determining the working status is normal; and requesting, via the first data centre to the second data centre, an interface switch in response to determining the working status is faulty.

[0027] In an embodiment, the method for detecting fault in a distributed computing environment further includes receiving, via the second data centre, the interface switch request from the first data centre; accessing, via the second data centre, the specific interface of the external service that was determined to be faulty; and receiving, via the second data centre, a service response from the external service.

[0028] In an embodiment, the service response includes at least one of status information or requested data associated with the specific interface. In an embodiment, the accessing of the specific interface of the external service via the first data centre or the second data centre includes using at least one of RESTful APIs, GraphQL, or WebSockets.

[0029] In an embodiment, the method for detecting fault in a distributed computing environment further includes determining, via the second data centre, the working status of the specific interface based on the received fault information and identifier; updating, via the second data centre, the working status of the specific interface to normal in response to determining the specific interface is operational; and transmitting, via the second data centre, the updated working status to the first data centre.

[0030] Embodiments of the present disclosure may be provided as a network of communicating devices (i.e. a “computerized network”). Embodiments of the invention may be also provided as a software application downloadable into a computer device to facilitate the method. The software application may be a computer program product, which may be stored on a non- transitory computer-readable medium on a tangible data-storage device (such as a storage device of a server, or one within a user device).

[0031] BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In the following, embodiments of the present invention will be described as non-limiting examples with reference to the accompanying drawings in which:

[0033] FIG. 1 is a block diagram showing an overview of a dual-active system architecture for managing faults in external services, according to an embodiment of the present disclosure.

[0034] FIG. 2 is a flowchart showing a method for detecting and managing faults in external services, according to an embodiment of the present disclosure.

[0035] FIG. 3 is a flowchart showing a method for selectively accessing interface services based on a determined working status, according to an embodiment of the present disclosure.

[0036] FIG. 4 is a flowchart showing a method for managing fault information and timing in a dualactive system architecture, according to an embodiment of the present disclosure.

[0037] FIG. 5 is a swimlane diagram illustrating a communication sequence for fault management between data centres and external services in a dual-active system, according to an embodiment of the present disclosure.

[0038] FIG. 6 is a block diagram showing the technical architecture 600 of a computing resources module for implementing some or all of the processes of Figures 2-5, according to certain embodiments of the present disclosure. DETAILED DESCRIPTION

[0039] In the following, embodiments of the present invention will be described as non-limiting examples with reference to the accompanying drawings in which:

[0040] As used herein, the terms "dual-active arrangement" or "dual-active configuration" refer to a system architecture where two data centres operate simultaneously and independently, with each data centre actively handling user services and serving as a real-time backup for the other. In this configuration, both data centres may be capable of processing requests and managing faults concurrently, ensuring continuous operation even if one data centre experiences issues.

[0041] As used herein, the term "local interface switch" refers to a process of redirecting access from a faulty interface associated with an external service in one data centre to a corresponding operational interface associated with the same external service in another data centre. This switching mechanism may be localized to a specific faulty external service, ensuring that other external services remain unaffected and minimizing disruption to the overall system operation.

[0042] As used in this disclosure, the terms "external interface services" or "external services" refer to third-party service providers that offer specific functionalities or services, such as payment processing, authentication, data feeds, or specialized computations, which are integrated into the system to deliver comprehensive solutions. These services are accessed through well- defined interfaces or APIs (Application Programming Interfaces) and are external to the company's own infrastructure. Each external service may have multiple specific interfaces or endpoints for different functions.

[0043] As used herein, the terms "interface" or "API" refer to a set of protocols, routines, and tools that define how software components should interact with each other. In the context of this invention, interfaces or APIs enable communication and data exchange between the system's application modules and the external services. Examples of interface protocols include RESTful APIs, GraphQL, and WebSockets.

[0044] As used herein, the terms "fault" or "faulty" refer to a state or condition where an external service or its specific interface is not functioning as expected or is unresponsive. A fault may be detected based on predefined criteria such as response time thresholds, error codes, or failed test transactions. The presence of a fault triggers the system's fault management processes to ensure continuity of service.

[0045] As used in this disclosure, the terms “component,” “module,” “system,” “apparatus,” “interface,” or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component or a module may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a controller and the controller can be a component or a module. One or more components / modules may reside within a process and / or thread of execution and a component may be localized on one computer and / or distributed between two or more computers.

[0046] Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and / or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. For instance, the claimed subject matter may be implemented as a computer-readable medium embedded with a computer executable program, which encompasses a computer program accessible from any computer-readable storage device or storage media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . .), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . .), smart cards, and flash memory devices (e.g., card, stick, key drive . . .).

[0047] FIG. 1 is a block diagram showing an overview of a dual-active system architecture 100 for managing faults in external services, according to an embodiment of the present disclosure.

[0048] The system architecture 100 includes a First Data Centre 102a and a Second Data Centre 102b. While this example describes two data centres, the system can be extended to include additional data centres as needed. The First Data Centre 102a and the Second Data Centre 102b are configured in a dual-active arrangement to ensure continuous system availability and fault tolerance. As used herein, a dual-active arrangement refers to a configuration where all data centres are simultaneously active and capable of processing requests, as opposed to a primary-backup configuration where one data centre is on standby. In various embodiments, each data centre contains identical modules, enabling continuous operation and failover capabilities in the event of faults or failures. In this context, failover capabilities may include the ability of the system 100 to automatically switch to the secondary data centre or component when the primary one fails, ensuring continuous operation. For example, each data centre includes a Network Module 104a, 104b, a Database Module 106a, 106b, a Computing Resources Module 108a, 108b, an Application Module 1 10a, 1 10b. These modules operate in coordination to manage faults in External Services 1 14. In some implementations, the system 100 may also incorporate a Load Balance Module 112a, 1 12b in each data centre. While not directly involved in the intelligent switching of service failures, the load balance module 112a or 112b, when present, may be configured to optimize the distribution of workload across the system components. This may include balancing the load of internal processes or user requests within the data centre.

[0049] The Network Module 104a, 104b in each of the data centres 102a, 102b may function as a primary communication network of the system 100. In some embodiments, each Network Module 104a, 104b facilitates the synchronisation and transmission 116 between the two data centres, ensuring real-time data synchronisation and transmission. Each Network Module 104a, 104b may, in certain implementations, employ advanced routing protocols and encryption mechanisms to secure inter-data centre communications.

[0050] The Database Module 106a, 106b in each data centre may be configured to function as a persistent storage layer for the system 100. For example, each database module 106a, 106b may store critical information such as fault data, interface identifiers, and operational logs. In some implementations, each database module 106a, 106b may employ a distributed database architecture to ensure data consistency across both data centres. Each database module 106a, 106b may store, for example, the names of faulty interfaces of external services and their associated storage durations, allowing for granular tracking of faults at the interface level. Each database module may be understood as a logically independent data storage space dedicated to performing service connection detection and intelligent data centre switching tasks.

[0051] The Computing Resources Module 108a, 108b in each data centre may serve as a main processing component of each data centre. The computing resources module 108a, 108b may include several modules configured to implement the fault management process of system 100. In example embodiments, these modules operate collaboratively to provide fault detection and management capabilities. A fault detection module may continuously monitor the status of external services 1 14. The fault detection module may employ various detection algorithms, such as heartbeat monitoring, response time analysis, and error pattern recognition, to identify issues at the level of specific interfaces rather than entire external services. Concurrently, a timing system module may manage temporal aspects of fault detection and resolution processing. In some implementations, the timing system module implements a storage timing mechanism that tracks the duration of stored fault information and compares it against predefined thresholds. For example, the storage timing may be compared with a pre-set storage duration to determine if a fault has been resolved.

[0052] A working status determination module may analyse the data generated by the fault detection and timing system modules to determine a current working status of a specific interface corresponding to the external services 1 14. In embodiments, the working status determination module may evaluate the stored fault information and the duration it has been stored to classify the interface status. For example, the working status may be obtained based on identification information assigned to specific faulty interfaces.

[0053] Based on the working status determination, an interface switching module may initiate a local interface switch if a fault status is detected. For example, the local interface switch may initiate a switch to redirect access from a first interface associated with the faulty external service in the first data centre to a second interface associated with the faulty external service in the second data centre, thereby isolating the interface switch to the faulty external service. This configuration enables precise fault management by allowing the system 100 to specifically address disruptions in individual interfaces of external services, ensuring that other interfaces remain unaffected and minimizing disruption to the overall system operation. As a result, the system 100 maintains uninterrupted operation in the first data centre while attempting to remedy the fault localized to the single affected interface in the second data centre.

[0054] The Application Module 1 10a, 1 10b in each data centre may host the software applications that interact with the External Services 114. In one or more embodiments, each application module includes RESTful APIs or other interface protocols to communicate with various external services. RESTful APIs, or Representational State Transfer APIs, may correspond to a standard way for software applications to communicate over the internet using HTTP protocols.

[0055] The Load Balance Module 1 12a, 112b in each data centre is configured to optimize the distribution of workload across the system components. In certain implementations, the load balance module is separate from and has no direct connection to the intelligent switching solution for service failures between the data centres.

[0056] The External Services 1 14 represent the third-party service providers with which the system 100 interacts. These may include, but are not limited to, payment gateways, data providers, and complex API-driven services. For example, an external service 114 might be a payment processing API that handles credit card transactions, a shipping logistics API that provides real-time tracking information, or a customer authentication service that verifies user identities. Each of these services may have multiple specific interfaces or endpoints. For instance, a payment processing API might have separate interfaces for initiating a transaction, checking transaction status, and processing refunds.

[0057] The system architecture 100 is configured to manage faults at the level of these specific interfaces rather than switching entire external service providers. This granular approach allows for more precise fault management. For example, if an "initiate transaction" interface of a payment processing API becomes unresponsive, the system 100 can switch just that specific interface to the second data centre, while continuing to use other interfaces of the same API (like "check transaction status") through the first data centre. The system 100 may perform a local interface switch, wherein the local interface switch includes redirecting access from a faulty interface in the first data centre to a corresponding operational interface in the second data centre, thereby isolating the switch to the affected interface. This approach contrasts with a less refined approach where an issue with any interface would result in switching all interactions with that external service to the second data centre. This specific interface switching capability is particularly valuable in complex systems where different interfaces of a single external service may have varying levels of criticality or usage. It allows the system 100 to maintain optimal performance and reliability by addressing faults only where necessary, minimizing disruption to the overall system operation.

[0058] The Synchronisation and Transmission component 116 represents the bidirectional communication channel between the two data centres. In some embodiments, this component 116 ensures both data centres maintain consistent information about fault statuses, interface identifiers, and operational decisions. The bidirectional communication channel 1 16 may be configured to perform real-time synchronization of fault information and faulty interface identifiers between the data centres.

[0059] In operation, the system 100 may perform a series of steps to manage faults. For example, the system 100 may check the specific interface status of the external services, store fault information if detected, assign an identifier to faulty interfaces, synchronize this information between data centres, determine the working status based on the stored information, and initiate a local interface switch if necessary. This process allows for efficient and targeted fault management in the dual-active system architecture.

[0060] FIG. 2 is a flowchart showing a method 200 for detecting and managing faults in external services, according to an embodiment of the present disclosure. The method 200 may be implemented by the dual-active system architecture 100 described in FIG. 1.

[0061] At step 202, the system 100 obtains an external service list. This list may be dynamically maintained and updated in each of the Database Modules 106a or 106b, indicating a current set of external services integrated and / or interacting with the system 100. For example, the list may include payment processing APIs, shipping logistics APIs, and customer authentication services, along with their specific interfaces such as “transition initiation” interface or “transaction status check” interface. The list may include not only the primary endpoints of each service but also auxiliary interfaces, fall-back URLs, and API versions. For example, a payment gateway external service may be represented by multiple interfaces or entries such as its transaction initiation endpoint, status check interface, and refund processing API.

[0062] At step 204, the system 100 obtains a pre-set detection period. The pre-set detection period determines the frequency at which the system 100 checks the status of the external services. This period may be configured in each computing resources module 108a, 108b and could be adjustable based on system requirements. The pre-set detection period may be adaptive, dynamically adjusted based on historical performance data, current system load, or even time of day. The system 100 may employ a multi-tiered approach, where different categories of services or individual interfaces have distinct detection periods. For example, critical financial transaction APIs might be monitored every few seconds, while less crucial services like analytics endpoints could be checked at longer intervals. The pre-set detection period may be determined based on operational experience, ensuring optimal monitoring frequency. For example, the pre-set detection period may be set to balance the need for timely fault detection with the desire to minimize unnecessary system overhead.

[0063] At step 206, the system 100 detects the external service list. Step 206 may be performed by the fault detection module within each computing resources module 108a, 108b. The detection process might include sending test requests to each interface on the list and analysing the responses. For example, a "ping" request could be sent to check basic connectivity, or a more complex test transaction might be attempted to verify full functionality.

[0064] Step 208 represents a decision point where the system 100 determines if a fault has been detected. This decision may be based on predefined criteria such as response time thresholds or specific error codes. If no fault is detected, the process loops back to step 206 to continue monitoring. If a fault is detected, the process moves to step 210.

[0065] At step 210, the system 100 stores information associated with the faulty interface of the external service and sets a storage time. This information is recorded in the Database Module 106a at the granular level of individual interfaces, not entire services. For example, if a payment processing service has multiple interfaces (e.g., "initiate payment", "check status", "process refund"), the system stores fault information for each interface independently.

[0066] The storage time is set as a duration longer than the pre-set detection period obtained in step 204. This ensures that the working status of the specific interface corresponding to the faulty interface name is determined to be abnormal when detected again, preventing premature fault resolution. Moreover, this approach enables the fault information for each specific interface to persist long enough for the system 100 to make informed decisions about that interface's status. The storage time may be implemented as follows: When a fault is first detected in a specific interface, the system records the current timestamp (T1 ) along with the fault information for that interface. The system 100 also calculates and stores an expiration timestamp (T2) by adding the storage time duration to T1 . During subsequent detection cycles, the system 100 compares the current time to T2 for each faulty interface. If the current time is less than T2, the fault for that specific interface is still considered active.

[0067] If a fault is detected again for the same interface before T2, the system 100 updates T2 for that interface by adding the storage time duration to the current timestamp, effectively extending the fault's active period for that specific interface. For example, if the pre-set detection period for a particular interface (such as "initiate payment") is 10 seconds, the system 100 might set the storage time to 11 seconds for that interface. This extra time allows for a buffer period during which the system 100 can re-check the status of that specific interface before considering its fault resolved.

[0068] This mechanism allows the system 100 to track how long a fault has persisted for each individual interface while also providing a means to automatically clear resolved faults after a specified duration. This granular approach enables the system to manage faults and perform switching at the interface level, rather than switching entire external services. For instance, if the "initiate payment" interface is faulty but the "check status" interface of the same service is working normally, only the "initiate payment" interface will be switched to the second data centre, while "check status" requests can still be processed through the first data centre.

[0069] At step 212, the system 100 may assign an identifier or identification information to the faulty interface of external service. The identifier could be implemented in various ways, depending on the specific needs of the system 100. For example, the identifier could be a simple sequential number, a timestamp-based code, or a more complex alphanumeric string. The purpose of this identifier is to uniquely mark and track the detected faulty interface. In examples, the identifier could encode multiple layers of information such as service category, specific API, fault type, and a unique incident number. For example, "PAY_API_INIT_001" might break down as PAY (payment category), API (interface type), IN IT (specific endpoint), and 001 (unique fault instance). This structured approach facilitates more efficient fault tracking, trend analysis, and automated response mechanisms.

[0070] Finally, in step 214, the system 100 obtains the working status based on the assigned identifier of step 212. This status is specific to the individual interface, allowing for granular management of faults within a single external service. During step 214, the Working Status Determination module within the Computing Resources Module (108a, 108b) may analyse the stored fault information and its duration to determine the current status of the interface. The working status may then be categorized as "Faulty", "Under Observation", or "Resolved" based on a predefined criterion. The status determination could also factor in the criticality of the service, current system load, and available fall-back options. In various embodiments, the working status of the specific interface of an external service can be determined using suitable existing technologies. These may include, but are not limited to, heartbeat detection, polling, or obtaining interface abnormal information based on log alarms. The system may employ one or a combination of these methods to continuously monitor the health of the specific interface.

[0071] In cases where multiple simultaneous faults occur, the system 100 is capable of processing multiple different faults asynchronously and independently. Each fault may be treated as a separate event, triggering its own detection, storage, and switching processes. This parallel processing ensures the overall normal operation of the system 100, even in the presence of multiple simultaneous faults.

[0072] FIG. 3 is a flowchart showing a method 300 for selectively accessing specific interfaces of external services based on a determined working status, according to an embodiment of the present disclosure. The method 300 may be implemented by the dual-active system architecture 100 described in FIG. 1.

[0073] At step 302, the system 100 reads the working status of a specific interface of an external service. The working status may be read by the working status determination module within one or both computing resources modules 108a, 108b of FIG. 1. The working status may be obtained based on the fault detection and timing information stored in one or both of the database modules 106a, 106b. For example, the system 100 may retrieve the latest status information for a specific interface, such as a payment processing API endpoint, from one of the database modules 106a or 106b. This status information may include details such as the last successful connection time, any recent fault occurrences, or the current operational state of the interface.

[0074] If the working status is determined to be "Normal", the process 300 proceeds to step 306. At this step, the system 100 acknowledges the normal status of the specific interface. The system 100 may record or update the normal status information, which could be used in subsequent processing steps or for system monitoring purposes. Following the normal status acknowledgment, at step 310, the system 100 proceeds to access the first data centre 102a. The access of the first data centre 102a may include internal system processes and may depend on the specific implementation of the dual-active system architecture of FIG.1 .

[0075] At step 314, the system 100 accesses the specific interface via the first application component. The access of the interface may include using the Application Module 1 10a in Data Centre 102a of FIG. 1 . The application module 110a may use appropriate protocols, such as RESTful APIs or other interface protocols, to interact with the external interface, as described in the system architecture of FIG. 1 .

[0076] Alternatively, if the working status is determined to be "Fault" at step 304, the process 300 moves to step 308. At step 308, the system 300 acknowledges the fault status of the specific interface of the external service. This acknowledgement may include triggering alert mechanisms within the system 100 and potentially initiating fault logging processes for further analysis.

[0077] Following the fault status acknowledgment, at step 312, the system 100 proceeds to access the second data centre 102b. The access of the second data centre 102b may include internal system processes and may depend on the specific implementation of the dual-active system architecture of FIG. 1 .

[0078] At step 316, the system 100 accesses the specific interface via the second application component. The access of the specific interface may include using the Application Module 110b in Data Centre 102b of FIG. 1. The application module 1 10b may use appropriate protocols, such as RESTful APIs or other interface protocols, to interact with the interface of the external service, as described in the system architecture of FIG. 1. This process allows for switching of individual interfaces rather than entire services. For instance, if the "initiate payment" interface is faulty in the first data centre, only that specific interface is switched to the second data centre, while other interfaces of the same payment service (like "check payment status") may continue to be accessed through the first data centre.

[0079] In the process 300 shown in FIG. 3, each of the Load Balance Modules 112a, 1 12b may be present in some implementations to manage workload distribution within individual data centres. In such implementations, they operate independently of the decision-making process for switching between data centres or in the management of external service access based on working status determinations. . Additionally, the communication channel 1 16 may provide consistent synchronisation of information about interface statuses and access decisions across both data centres 102a and 102b.

[0080] FIG. 4 is a flowchart illustrating a method 400 for managing fault information and timing in a dual-active system architecture, according to an embodiment of the present disclosure. The method 400 may be implemented by the system 100 described in FIG. 1 and represents an alternative implementation of steps 208 and 210 from FIG. 2. In particular, the method 400 introduces additional decision points and actions for processing both new and recurring faults, as well as a timing mechanism for determining fault resolution. At step 402, the system 100 stores fault information specific to individual interfaces of external services. In embodiments, the fault information may be stored in the database modules 106a or 106b of each data centre of FIG. 1. This storage process may be coordinated by each of the Computing Resources Modules 108a or 108b in conjunction with their respective database modules 106a or 106b in each data centre, as shown in FIG. 1 . The fault information may include details such as the name of the faulty external service, the type of fault detected, and the time of detection. For example, if a payment processing API fails to respond within a specified timeframe, the system may store this information along with a timestamp. The fault information may be stored in a structured format, allowing for efficient retrieval and analysis. For example, the fault information might include fields for fault ID, service name, fault type, timestamp, and current status.

[0081] At step 404, the system 100 traverses the database for existing fault entries. The traversal process may include searching through the stored fault information to determine if the current fault has been previously recorded. This traversal may be executed by the Computing Resources Module 108a or 108b of each data centre using querying functions stored in their respective Database Modules 106a or 106b of FIG. 1. The traversal process may be performed using database querying techniques appropriate to the specific database implementation used in the Database Module 106a or 106b of each data centre. The traversal process may use indexing techniques to optimize search performance, particularly in systems with large volumes of fault data.

[0082] Step 406 represents a decision point where the system determines if an entry for the current fault already exists in the database. This decision may be based on matching criteria such as the specific interface service name and fault type.

[0083] If an entry exists (YES path from step 406), the process moves to step 408. At step 408, the system 100 updates the first storage duration to a second storage duration. This update may include extending the time for which the fault information will be retained in the database. For example, if the original storage duration was set to 2 minutes, it might be extended to 3 minutes to allow for continued monitoring of the recurring fault. The second storage duration may be calculated based on factors such as the frequency of the fault's occurrence, its impact on system performance, or predefined escalation policies.

[0084] If no entry exists (NO path from step 406), the process 400 proceeds to step 410, where the system 100 sets the first storage duration. This storage duration may be predetermined based on the type of interface service or the nature of the fault. For example, a minor fault in a non- critical service might be given a shorter storage duration than a major fault in a critical service. At step 412, the system initiates a timing system to obtain a storage timing. This step may be performed by the timing system module within the computing resources module 108a, 108b of FIG. 1. The timing system tracks how long the fault information has been stored and may be synchronized across both data centres 102a and 102b to ensure consistent fault duration tracking in the dual-active architecture. This synchronization may be facilitated by the communication channel 1 16 of FIG. 1 .

[0085] At step 414, the system 100 compares the storage timing with the first or second storage duration. This comparison is made for each specific interface that has been flagged as faulty, allowing for independent management of different interfaces within the same external service. Moreover, this comparison determines whether the fault condition has persisted beyond an expected timeframe. The system 100 retrieves the current storage timing, which represents how long the fault information has been stored in the database, and compares it with either the first storage duration (set in step 410) or the second storage duration (updated in step 408), depending on whether it's a new or recurring fault. This comparison may be performed at regular intervals, with the frequency potentially based on system parameters or the nature of the fault. The comparison process provides updated fault condition data for the subsequent decision-making step, ensuring that the system has current information about the persistence of the fault in the external service. These comparison and decision-making processes may be executed within the Computing Resources Module 108a, 108b of FIG. 1 , utilizing processing capabilities distributed across both data centres 102a and 102b.

[0086] At step 416, the system 100 determines if the timing is equal to the duration for each specific interface. This decision point assesses whether the fault condition should be considered resolved or if it requires further attention. If the timing is not equal to the duration (No path from step 416), the process loops back to step 414 for continued comparison. If the timing is equal to the duration for a particular interface (Yes path from step 416), the process moves to step 418, where the system resumes normal operation. This step may involve updating the status of the interface of the external service to "Normal" as described in step 306 of FIG. 3. Upon completion of step 418, the process 400 concludes.

[0087] Throughout the fault detection and switching processes, the system 100 may maintain comprehensive logs. These include fault logs and dual-active switching work logs, which are recorded synchronously. These logs can be analysed by maintenance personnel to troubleshoot issues and optimize system performance. In the event that the intelligent switching mechanism itself fails, the system 100 allows for manual switching operations to be performed according to existing technologies. This manual fall-back option ensures that the system can continue to operate even in unforeseen circumstances. FIG. 5 is a swimlane diagram illustrating a communication sequence 500 for fault management between data centres and external services in a dual-active system, according to an embodiment of the present disclosure. The sequence 500 may be implemented by the system 100 described in FIG. 1 and depicts the interactions between the First Data Centre 102a, Second Data Centre 102b, and External Services 114 during fault detection, management, and service access processes.

[0088] At step 502, the First Data Centre 102a initiates a check of the specific interface status of the External Services 1 14. This could be, for example, checking the status of the "initiate transaction" interface of a payment processing API. This status check may be executed by the Computing Resources Module 108a, and in conjunction with the Application Module 110a for formulating the status check request. The status check may include sending one or more test signals or requests to the External Services 114 to assess their operational status and responsiveness.

[0089] At step 504, the External Services 114 returns the interface-specific status to the First Data Centre 102a. This response may include details such as response time, error codes (if any), or specific performance metrics. The Network Module 104a may process the receipt of this status information.

[0090] At step 506, the First Data Centre 102a stores fault information, sets the storage time, and assigns an identifier to the faulty interface. In some embodiments, the Database Module 106a may be utilized for storing the fault information. The Computing Resources Module 108a may be configured to manage the processes of setting the storage time and assigning the identifier. The multiple operations of step 506 enable the system 100 to create a comprehensive record of the detected fault, including for example temporal data and a unique identifier, which facilitates subsequent fault tracking and management operations. The storage time setting may determine how long the fault information is retained, while the assigned identifier allows for efficient referencing of the specific fault instance within the system 100.

[0091] At step 508, the First Data Centre 102a performs a synchronization operation to transmit the fault information and faulty interface identifier to the Second Data Centre 102b. In some embodiments, this synchronization may be facilitated by the synchronisation and transmission communication channel 116 of the system. The synchronization operation ensures that both data centres maintain consistent fault information, thereby enhancing the reliability and fault tolerance of the dual-active system architecture.

[0092] At Step 510, the First Data Centre 102a executes a process to determine the working status based on the assigned identifier. This determination may be performed by a working status determination module, which in some implementations may be integrated within a Computing Resources Module of the First Data Centre 102a. The working status determination process may assess the current operational state of the specific interface, utilizing the identifier assigned in previous steps to track and evaluate the fault condition of the specific interface. For example, the working status determination process may include verifying whether the fault condition initially detected and recorded with the identifier is still present or has been resolved based on the most recent status check.

[0093] If the status is determined to be normal, step 512 is executed, where the First Data Centre 102a accesses the specific interface of the External Services 114. For instance, it might use the "initiate transaction" interface of the payment API. This access may be managed by the Application Module 110a, using appropriate protocols such as RESTful APIs, GraphQL, and WebSockets.

[0094] In response, at step 514, the External Services 114 returns a service response to the First Data Centre 102a. This service response may include status information about the specific interface, such as whether it's operational or experiencing issues. The response might also contain any requested data if the interface is functioning normally.

[0095] If a fault status is determined for the specific interface, step 516 is initiated, where the First Data Centre 102a requests a local interface switch from the Second Data Centre 102b. This request implements the local switching capability, allowing the system 100 to redirect access for the specific faulty interface to the second data centre while maintaining other operations through the first data centre.

[0096] Following the switch request, in step 518, the Second Data Centre 102b accesses the specific interface of the External Services 1 14. This access may be managed by the Application Module 110b of the Second Data Centre, utilizing appropriate protocols to interact with the external service such as RESTful APIs, GraphQL, and WebSockets.

[0097] At step 520, the External Services 1 14 return a service response to the Second Data Centre 102b. This response may be similar in nature to the one described in step 514, including status information or requested data related to the specific interface. Sequence 500 illustrates the system's 100 capability to detect faults, manage fault information, and perform local interface switching between data centres to maintain service continuity. Furthermore, this sequence 500 shows the system’s 100 effectiveness in processing issues with external services at the interface level, ensuring robust fault management without disrupting the overall dual active operation of system 100. FIG. 6 is a block diagram showing the technical architecture 600 of a computing resources module for implementing some or all of the processes of Figures 2-5. The technical architecture includes a processor 622 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 624 (such as disk drives), read only memory (ROM) 626, random access memory (RAM) 628. The RAM 628 may be partitioned to efficiently process different tasks, such as fault detection, timing system management, and database operations. The processor 622 may be implemented as one or more CPU chips. The technical architecture may further comprise input / output (I / O) devices 630, and network connectivity devices 632. The network connectivity devices 632 may include support for redundant connections and protocols specific to data centre communications, ensuring reliable connectivity with other data centres and external services.

[0098] The secondary storage 624 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 628 is not large enough to hold all working data. Secondary storage 624 may be used to store programs which are loaded into RAM 628 when such programs are selected for execution.

[0099] In this embodiment, the secondary storage 624 has an order processing component 624a comprising non-transitory instructions operative by the processor 622 to perform various operations of the method of the present disclosure. Additionally, the secondary storage 624 may contain specialized software components such as a fault detection module, a switching decision module, a timing system module, and a database management module. Each of these modules is designed to execute specific aspects of the fault management process. For example, the fault detection module identifies issues with externals, the switching decision module determines when to switch between data centres or interfaces, the timing system module tracks fault durations, and the database management module administers storage and retrieval of fault information.

[0100] The ROM 626 is used to store instructions and perhaps data which are read during program execution. The secondary storage 624, the RAM 628, and / or the ROM 626 may be referred to in some contexts as computer readable storage media and / or non-transitory computer readable media.

[0101] I / O devices 630 may include printers, video monitors, liquid crystal displays (LCDs), plasma displays, touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices.

[0102] The processor 622 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk-based systems may all be considered secondary storage 624), flash drive, ROM 626, RAM 628, or the network connectivity devices 632. While only one processor 622 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors. The processor 622 may also include specialized hardware for accelerating certain operations, such as pattern matching for rapid fault detection or cryptographic functions for secure communication between data centres.

[0103] Although the technical architecture is described with reference to a computer, it should be appreciated that the technical architecture may be formed by two or more computers in communication with each other that collaborate to perform a task. For example, but not by way of limitation, an application may be partitioned in such a way as to permit concurrent and / or parallel processing of the instructions of the application. Alternatively, the data processed by the application may be partitioned in such a way as to permit concurrent and / or parallel processing of different portions of a data set by the two or more computers. In an embodiment, virtualization software may be employed by the technical architecture 600 to provide the functionality of a number of servers that is not directly bound to the number of computers in the technical architecture 600. This virtualization capability can be particularly useful in implementing the dual-active data centre configuration, allowing for flexible allocation of resources between datacentres and enabling efficient local interface switching as described in the disclosure. In an embodiment, the functionality disclosed above may be provided by executing the application and / or applications in a cloud computing environment. Cloud computing may comprise providing computing services via a network connection using dynamically scalable computing resources. A cloud computing environment may be established by an enterprise and / or may be hired on an as-needed basis from a third-party provider. The cloud computing environment can provide the scalability needed to handle increasing numbers of interfaces or data centres, allowing the fault management system to expand as needed.

[0104] To ensure high availability and fault tolerance, critical components of the technical architecture 600 may be duplicated or implemented with redundancy. This may include redundant power supplies, RAID storage configurations for the secondary storage 624, and failover capabilities for the processor 622 and network connectivity devices 632. These fault-tolerant features help maintain the integrity and continuity of the fault management system itself.

[0105] By programming and / or loading executable instructions onto the technical architecture, at least one of the CPU 622, the RAM 628, and the ROM 626 are changed, transforming the technical architecture in part into a specific purpose machine or apparatus having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules.

[0106] Whilst the foregoing description has described exemplary embodiments, it will be understood by those skilled in the art that many variations of the embodiments can be made within the scope of the invention as defined by the claims. Moreover, features of one or more embodiments may be mixed and matched with features of one or more other embodiments.

Claims

CLAIMS1. A system for managing faults in a distributed computing environment, the system comprising: a first data centre and a second data centre configured in a dual-active arrangement, wherein each of the first and second data centres include: a network module configured to facilitate synchronisation and transmission between the first data centre and the second data centre; a database module; an application module configured to host software applications that interact with the external services; and a computing resources module configured to obtain an external service list, obtain a pre-set detection period, detect a fault corresponding to a specific interface of a faulty external service, store fault information associated with the specific interface, assign an identifier to the specific interface, and obtain a working status based on the assigned identifier.

2. The system of claim 1 , wherein the computing resources module includes a fault detection module configured to monitor a status of a plurality of specific interfaces of the external services.

3. The system of claim 1 or 2, wherein the computing resources module is configured to generate the identifier by encoding at least one of a service category, a specific interface identifier, an interface type, a fault type, or a unique incident number associated with the specific interface of the faulty external service.

4. The system of any one of claims 1 -3, wherein the computing resources module includes a fault detection module configured to monitor a status of specific interfaces of the external services and a working status determination module configured to analyse the stored fault information and determine the working status of the specific interface corresponding to the faulty external service.

5. The system of any one of claims 1-4, wherein the computing resources module includes an interface switching module configured to initiate a local interface switch to redirect access for a specific faulty interface of an external service from the first data centre to the second data centre.

6. The system of any one of claims 1 -5, wherein the computing resources module includes a timing system module configured to track a storage timing associated with the stored faultinformation and compare the storage timing to a predetermined storage duration to determine a persistence of the fault in the faulty external service.

7. A method for detecting faults, the method comprising: obtaining an external service list; obtaining a pre-set detection period; detecting a fault in an external service by monitoring the external service list based on the pre-set detection period; storing fault information associated with the faulty external service; setting a storage time as a duration longer than the pre-set detection period; assigning an identifier to the faulty external service; determining a working status of the faulty external service based on the assigned identifier; and determining whether to access the external service via a first application component in a first data centre or the external service via a second application component in a second data centre based on the determined working status.

8. The method of claim 7, wherein the first data centre and the second data centre are configured in a dual-active arrangement and synchronize the fault information via a bidirectional communication channel.

9. The method of claim 7 or 8, wherein the external service list includes a plurality of external services and a plurality of specific interfaces associated with each external service.

10. The method of any one of claims 7-9, further comprising: receiving, via the first application component, a first service response from the external service when accessing the external service via the first data centre; and receiving, via the second application component, a second service response from the external service when accessing the external service via the second data centre.11 . A method for managing faults, the method comprising: detecting a fault in an external service by monitoring an external service list; storing fault information associated with a faulty external service in a database in response to detecting the fault; traversing the database for an existing fault entry corresponding to the faulty external service; updating a first storage duration associated with the existing fault entry to a second storage duration in response to identifying an existing faulty entry; initiating a timing system to obtain a storage timing;comparing the storage timing to the second storage duration; and updating a working status of the faulty external service to normal in response to the storage timing being equal to the second storage duration.

12. The method of claim 1 1 , further comprising: setting the first storage duration associated with the fault information to a predetermined value in response to identifying no existing fault entry corresponding to the faulty external service and comparing the storage timing to the first storage duration.

13. The method of claim 1 1 or 12, further comprising assigning an identifier to the faulty external service after updating the working status of the faulty external service to normal.

14. The method of any one of claims 11 -13, wherein the first storage duration is set based on a type of the faulty external service or a nature of the fault.

15. The method of any one of claims 11 -14, wherein the second storage duration is determined based on at least one of a frequency of fault occurrence, an impact on system performance, or a predefined policy.

16. A method for detecting fault in a distributed computing environment, the method comprising: initiating, via a first data centre, a status check of a specific interface associated with an external service; receiving, via the first data centre, an interface status from the external service; storing, via the first data centre, fault information associated with the specific interface; assigning, via the first data centre, an identifier to the specific interface in response to the interface status indicating a fault; transmitting, via the first data centre, the fault information and the identifier to a second data centre; determining, via the first data centre, a working status of the specific interface based on the identifier; accessing, via the first data centre, the specific interface of the external service in response to determining the working status is normal; and requesting, via the first data centre to the second data centre, an interface switch in response to determining the working status is faulty.

17. The method of claim 16, further comprising receiving, via the second data centre, the interface switch request from the first data centre; accessing, via the second data centre, the specific interface of the external service that was determined faulty; and receiving, via the second data centre, a service response from the external service.

18. The method of claim 16 or 17, wherein the service response includes at least one of status information or requested data associated with the specific interface.

19. The method of any one of claims 16-18, wherein accessing the specific interface of the external service via the first data centre or the second data centre includes using at least one of RESTful APIs, GraphQL, or WebSockets.

20. The method of any one of claims 16-19, further comprising: determining, via the second data centre, the working status of the specific interface based on the received fault information and identifier; updating, via the second data centre, the working status of the specific interface to normal in response to determining the specific interface is operational; and transmitting, via the second data centre, the updated working status to the first data centre.

Images