Patent Publication Number: US-2023144396-A1

Title: Regenerating transaction objects when processing fails on a transaction exchange platform

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation-in-part of U.S. application Ser. No. 17/389,045, filed on Jul. 29, 2021 and entitled “Transaction Exchange Platform with Watchdog Microservice,” which is a continuation of U.S. application Ser. No. 16/723,545 (now U.S. Pat. No. 11,080,120), filed on Dec. 20, 2019 and entitled “Transaction Exchange Platform with Watchdog Microservice,” the entireties of which are incorporated herein by reference. 
     This application is related to the following U.S. patent applications, filed on the same day:
         Attorney Docket No. 009033.00489, entitled “Consensus Key Locking with Fast Local Storage for Idempotent Transactions” and filed concurrently herewith; and   Attorney Docket No. 009033.00589, entitled “Watchdog Microservice to Resolve Locks When Processing Fails On A Transaction Exchange Platform” and filed concurrently herewith.
 
Each of the related applications is incorporated by reference herein in its entirety for all purposes.
       

    
    
     FIELD OF THE INVENTION 
     Aspects of the disclosure relate generally to a transaction exchange platform. More specifically, aspects of the disclosure may provide for managing locks when resources are accessed from geographically disparate regions. Additional aspects of the disclosure may provide for resolving locks when processing of transaction objects that hold the lock for a resource fail. 
     BACKGROUND OF THE INVENTION 
     Computer systems and applications have revolutionized the handling of transactions and greatly accelerated clearing and settlement processes. Software solutions have been created to facilitate processing, validation, and approval of transactions. These systems serve to interface transaction originators with clearing and settlement operations, allowing transactions to flow between enterprises and facilitating the movement of trillions of dollars per year. However, some transactions handled by the transaction exchange platform are extremely sensitive to duplicate data. Because of this, the transaction exchange platform must guarantee idempotent transactions have the ability to lock a key, resource, and/or data, across all instances, in all regions. Existing solutions suffer from shortcomings that cannot guarantee idempotent transactions. For example, traditional write forward mechanisms, such as Redis Active-Active, have a window where cross-region writes eventually become consistent and could allow instances in both regions to believe that they own the lock, resulting in the potential for duplicate processing. Furthermore, existing database solutions are unable to guarantee idempotent transactions have the ability to lock a key, resource, and/or data, across all instances, in all regions. In this regard, relational databases, such as AWS Aurora (MySQL Multi-mater), have performance issues with frequent conflict resolution, which is to be expected when processing replicated streaming data in multiple regions. Other databases, like Cockroach DB, etcd, RedisRaft, and the like, may offer consensus protocol solutions, like Raft, which may provide a locking mechanism. However, these other databases may attempt to version each update, which would require consensus overhead that would increase latency. Additionally or alternatively, these other databases may allow subsequent changes to be made provided there was not a simultaneous write conflict. Another problem is that these other databases tend to hold a limited amount of data due to the synchronization of snapshots. Moreover, the databases that implement consensus protocols traditionally solve for a single instance lock acquisition and are, therefore, relatively slow and unable to scale. Accordingly, existing database solutions that use the consensus protocol for all read and write transactions would incur too much overhead and latency to be able to function effectively in a production environment. 
     Aspects described herein may address these and other shortcomings present in existing solutions. Novel aspects discussed herein may implement a transaction exchange platform using a streaming data platform and microservices to provide faster, more dynamic, and more robust processing and approval of transactions. The novel transaction exchange platform may provide benefits such as improving the flexibility and reliability of transaction approval and processing systems, while offering robust record keeping for transaction audit purposes. The novel platform may also provide other benefits such as support for legacy and ongoing operations, solving for new and changing requirements in today&#39;s environment, and adapting to future technologies 
     SUMMARY OF THE INVENTION 
     The following presents a simplified summary of various aspects described herein. This summary is not an extensive overview, and is not intended to identify key or critical elements or to delineate the scope of the claims. The following summary merely presents some concepts in a simplified form as an introductory prelude to the more detailed description provided below. 
     Aspects described herein may relate to a locking mechanism that enables lock acquisition consensus across a geographically distributed transaction exchange platform. The locking mechanism may leverage a consensus protocol only when acquiring a lock on a key value and handles all other aspects of data access with a local fast write forward system. This is an improvement over existing systems since leveraging consensus protocol only when acquiring a lock on a key value, and handling all other aspects of data access with a fast write forward system, guarantees idempotent transactions in a system with data replicated across regions. By limiting the consensus protocol interactions only to writing unique keys—which is done once per transaction, the locking mechanism improves performance by storing metadata and/or application-related state details in the local cache system after the lock is acquired. This further improves the performance and reliability of the distributed locking mechanism. 
     Corresponding apparatus, systems, and computer-readable media are also within the scope of the disclosure. 
     These features, along with many others, are discussed in greater detail below. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present disclosure is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which: 
         FIG.  1    depicts an example of a computing device that may be used in implementing one or more aspects of the disclosure in accordance with one or more illustrative aspects discussed herein; 
         FIG.  2    depicts an example operating environment used to discuss illustrative aspects of a transaction exchange platform according to one or more aspects of the disclosure; 
         FIG.  3 A  depicts an example transaction exchange platform according to one or more aspects of the disclosure; 
         FIGS.  3 B- 3 C  depict example structures for microservices according to one or more aspects of the disclosure; 
         FIG.  4    depicts an illustrative workflow as a directed acyclic graph according to one or more aspects of the disclosure; 
         FIG.  5    depicts an illustrative method for processing transactions on a streaming data platform according to one or more aspects of the disclosure; 
         FIG.  6    depicts an example transaction exchange platform having a configuration interface according to one or more aspects of the disclosure; 
         FIGS.  7 A- 7 C  depict illustrative changes to workflows, as graphs, according to one or more aspects of the disclosure; 
         FIG.  8    depicts an illustrative method for reconfiguring microservices according to one or more aspects of the disclosure; 
         FIG.  9    depicts an example transaction exchange platform having a snapshot microservice and a watchdog microservice according to one or more aspects of the disclosure; 
         FIGS.  10 - 15    depict illustrative methods for operation of the snapshot microservice and the watchdog microservice according to one or more aspects of the disclosure; 
         FIG.  16    depicts an example of a transaction exchange platform according to one or more aspects of the disclosure; 
         FIG.  17    depicts an example of a method for obtaining a lock on a resource according to one or more aspects of the disclosure; 
         FIG.  18    depicts an example of a method for releasing a lock on a resource according to one or more aspects of the disclosure; 
         FIGS.  19 A and  19 B  depict an example of a method for resolving a lock when processing of a transaction that owns the lock fails according to one or more aspects of the disclosure; and 
         FIG.  20    depicts an example of a flowchart illustrating an example method for determining to replay a transaction on a transaction exchange platform according to one or more aspects of the disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which aspects of the disclosure may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present disclosure. Aspects of the disclosure are capable of other embodiments and of being practiced or being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. Rather, the phrases and terms used herein are to be given their broadest interpretation and meaning. The use of “including” and “comprising” and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. 
     By way of introduction, aspects described herein may relate to a transaction exchange platform using a streaming data platform and microservices to process transactions according to review and approval workflows. A transaction exchange platform, according to one or more aspects discussed herein, may provide a version agnostic data streaming, reactive microservice solution that facilitates payment related workflows to be executed. Although the term “microservice” is used throughout this disclosure, aspects are not limited to “microservices” as used in cloud computing contexts. Generally, as used herein “microservice” may refer to a technology process that does work on an object on a streaming data platform in any given step of a workflow. Aspects discussed herein may refer to “approval” of transactions. This generally refers to the processing necessary to move a transaction through the transaction exchange platform from intake to output, and does not necessarily mean that the payment exchange platform affirmatively approves the nature of the transaction. Instead, “approval” as used herein may refer to processing, validating, and/or affirmatively approving a transaction according to a workflow indicating the steps necessary to process a transaction on the platform before it is ready for output to downstream processors. 
     Before discussing these concepts in greater detail, however, several examples of a computing device that may be used in implementing and/or otherwise providing various aspects of the disclosure will first be discussed with respect to  FIG.  1   . 
       FIG.  1    illustrates one example of a computing device  101  that may be used to implement one or more illustrative aspects discussed herein. For example, computing device  101  may, in some embodiments, implement one or more aspects of the disclosure by reading and/or executing instructions and performing one or more actions based on the instructions. In some embodiments, computing device  101  may represent, be incorporated in, and/or include various devices such as a desktop computer, a computer server, a mobile device (e.g., a laptop computer, a tablet computer, a smart phone, any other types of mobile computing devices, and the like), and/or any other type of data processing device. 
     Computing device  101  may, in some embodiments, operate in a standalone environment. In others, computing device  101  may operate in a networked environment. As shown in  FIG.  1   , various network nodes  101 ,  105 ,  107 , and  109  may be interconnected via a network  103 , such as the Internet. Other networks may also or alternatively be used, including private intranets, corporate networks, LANs, wireless networks, personal networks (PAN), and the like. Network  103  is for illustration purposes and may be replaced with fewer or additional computer networks. A local area network (LAN) may have one or more of any known LAN topology and may use one or more of a variety of different protocols, such as Ethernet. Devices  101 ,  105 ,  107 ,  109  and other devices (not shown) may be connected to one or more of the networks via twisted pair wires, coaxial cable, fiber optics, radio waves or other communication media. 
     As seen in  FIG.  1   , computing device  101  may include a processor  111 , RAM  113 , ROM  115 , network interface  117 , input/output interfaces  119  (e.g., keyboard, mouse, display, printer, etc.), and memory  121 . Processor  111  may include one or more computer processing units (CPUs), graphical processing units (GPUs), and/or other processing units such as a processor adapted to perform computations associated with machine learning. I/O  119  may include a variety of interface units and drives for reading, writing, displaying, and/or printing data or files. I/O  119  may be coupled with a display such as display  120 . Memory  121  may store software for configuring computing device  101  into a special purpose computing device in order to perform one or more of the various functions discussed herein. Memory  121  may store operating system software  123  for controlling overall operation of computing device  101 , transaction exchange platform software  125  for instructing computing device  101  to perform aspects discussed herein, machine learning software  127 , smart database  129 , and other applications  131 . Machine learning software  127  may be incorporated in and may be a part of transaction exchange platform software  125 . In embodiments, computing device  101  may include two or more of any and/or all of these components (e.g., two or more processors, two or more memories, etc.) and/or other components and/or subsystems not illustrated here. 
     Devices  105 ,  107 ,  109  may have similar or different architecture as described with respect to computing device  101 . Those of skill in the art will appreciate that the functionality of computing device  101  (or device  105 ,  107 ,  109 ) as described herein may be spread across multiple data processing devices, for example, to distribute processing load across multiple computers, to segregate transactions based on geographic location, user access level, quality of service (QoS), etc. For example, devices  101 ,  105 ,  107 ,  109 , and others may operate in concert to provide parallel computing features in support of the operation of control logic  125  and/or software  127 . 
     One or more aspects discussed herein may be embodied in computer-usable or readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices as described herein. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The modules may be written in a source code programming language that is subsequently compiled for execution, or may be written in a scripting language such as (but not limited to) HTML or XML. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like. Particular data structures may be used to more effectively implement one or more aspects discussed herein, and such data structures are contemplated within the scope of computer executable instructions and computer-usable data described herein. Various aspects discussed herein may be embodied as a method, a computing device, a data processing system, or a computer program product. 
     Having discussed several examples of computing devices which may be used to implement some aspects as discussed further below, discussion will now turn to methods and techniques for implementing a transaction exchange platform. 
     Transaction Exchange Platform—Processing Streaming Transaction Data Using Microservices 
     Aspects described herein may provide a transaction exchange platform implemented using a streaming data platform (SDP) and a plurality of microservices to process transactions according to workflows corresponding to different transaction types. Microservices on the transaction exchange platform may be configured to retrieve transactions having a current workflow stage that is assigned to the microservice from the SDP. The microservice may perform one or more steps of the approval/review workflow for the type of transaction, update the status of the object, and put it back to the SDP. Other microservices, later in the workflow, may see that the current workflow status of a transaction indicates that earlier pre-requisite processing steps have completed and may accordingly retrieve the transaction objects and perform their respective workflow steps. When the current workflow stage of a transaction indicates that all requisite steps of the workflow have been completed, the transaction may be removed from the SDP of the transaction exchange platform and output to downstream systems for further processing. 
     A high level system  200  for processing transactions, such as payments, is illustrated in  FIG.  2   . Transaction processing system  200  may broadly illustrate the flow of transactions from origination source  205  through to settlement systems  220 . Transactions handled by system  200  may take any suitable form, generally as payment transactions. Example types of payment transactions include: wires, automated clearing house (ACH) payments, checks, cashier checks, real-time payments (RTP), credit cards, and/or many other types of payment transactions. Other factors that may inform the “type” of a transaction may include whether the transaction originates domestically or internationally, whether the destination is domestic or international, an amount of the transaction, the identity of one or more financial entities associated with the transaction, and the like. For purposes of the discussion herein, a transaction type may be relevant primarily for informing the review/approval steps that should be applied to the transaction prior to final settlement. 
     Transactions may begin at origination sources  205 . For example, if a customer were to purchase a donut at a bakery using a credit card, the transaction may be sent via a point-of-sale (POS) terminal at the bakery to a payment processor. As another example, an investor may cause a wire payment to be sent to their broker via a banking website. The banking website may receive the wire payment transaction and begin the process of facilitating settlement of the wire transaction via a transaction processing system  200 . 
     Transactions may be routed to settlement systems  220  to effect the transfer of the monies indicated in the transaction. For example, the wire transaction may be routed to respective financial institutions associated with the investor and broker to indicate the respective debit/credit to their accounts. However, substantial review and approval processing may be required before a transaction may be settled. This processing may involve regulatory, security, and/or risk management. 
     Transaction exchange platform  210  may serve as an interface between the origination source  205  and settlement systems  220 , and according to some aspects may implement the transaction review and approval workflow for each supported transaction type. Origination sources  205  may send transactions to transaction exchange platform  210  for review and approval processing, and ultimately for routing to settlement systems  220 . Transaction exchange platform  210  may be provided by the same entity operating settlement systems  220  and/or one or more of origination sources  205 , or may be provided by a third-party entity. 
     Transaction exchange platform  210  may perform the review and approval processing for transactions. This may include interfacing with clearing systems  215 . Clearing systems  215  may provide regulatory, security, and/or risk management support for transactions. For example, transactions may be referred to systems provided by the U.S. Federal Reserve as part of a clearance process. As another example, the identities of the parties to the transaction may need to be evaluated against various criteria in support of anti-money laundering or other such efforts. Clearing systems  215  may be provided as part of transaction exchange platform  210 , or as logically separate systems. Clearing systems  215  may be provided by the entities operating origination sources  205 , transaction exchange platform  210 , settlement systems  220 , government entities, and/or other third parties. 
     Transaction exchange platform  210  may interface with clearing systems  215  to complete review and approval processing on the transaction. Transactions that are approved on transaction exchange platform  210  may be routed to settlement systems  220  for settlement and/or further processing. 
       FIG.  3 A  illustrates a system  300  that may provide further details of a novel transaction exchange platform  320  than provided in  FIG.  2   , according to some aspects described herein. Similarly, transactions may originate at transaction origination sources  303  and route to downstream settlement systems, illustrated in  FIG.  3 A  as enterprise systems and users  350 . 
     Transaction exchange platform  320  may serve to perform review and approval workflow processing on transactions received from transaction origination sources  303  via enterprise transaction intermediary services  305 . Transaction origination sources  303  may include both first- and third-party sources of transactions. The enterprise providing transaction exchange platform  320  may provide transaction intermediary services  305  to receive transactions, whether from third-parties or not, and route those transactions to transaction exchange platform  320 . Enterprise transaction intermediary service  305  may perform validation, pre-processing, standardization, and/or any other suitable processing to prepare transactions for further handling by transaction exchange platform  320 . 
     Transactions may be sent to transaction exchange platform  320  via application programming interfaces (APIs), such as API  311  and API  313 . The APIs may validate aspects of the transaction details, and may package and/or standardize transactions into transaction objects suitable for processing on transaction exchange platform  320 . In some implementations, transaction exchange platform  320  may provide different APIs for each type of transaction. For example, API  311  may correspond to ACH transactions while API  313  corresponds to wire transactions. In some implementations, fewer APIs (such as a single centralized API) may be used to flexibly validate and initialize transactions for processing by transaction exchange platform  320 . The APIs for interfacing with transaction exchange platform  320  may comprise a number of components, such as a public API front-end, basic input validation logic, message level integrity processes, monitoring, and/or integration aspects. 
     Transaction objects may be pushed to a streaming data platform (SDP)  325  underlying transaction exchange platform  320 . Streaming data platforms, such as those based on the Apache Kafka open-source platform, may be used to process real-time data in computer systems. Message objects pushed to the streaming data platform may be read by consumer software modules, processed, and put back to the streaming data platform. Transaction objects on SDP  325  may be subject to processing by microservices on transaction exchange platform  320 , such as microservice  331 , microservice  332 , and microservice  333 . The microservices can read and write transaction objects from/to SDP  325 . Objects on SDP  325  may proceed logically through time, e.g. t 0  through t n , as they progress through stages of the workflow associated with a corresponding transaction type. 
     Transaction objects, such as transaction object  307 , may include transaction details, addenda, and transaction metadata. The transaction details and/or addenda may include the particulars of the transaction, such as the parties and/or accounts involved, as well as the amount of the payment. Addenda data of the transaction object may include, e.g., ABA routing numbers and other details that may be added, updated, and/or processed by the microservices on transaction exchange platform  320 . The transaction metadata may include at least an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. In some implementations, discussed further herein, the transaction metadata may also include workflow version information. 
     As an example, transaction object  307  may include the following: 
                                            {            transaction ID : a SHA256 encoded token            workflow type : ACH            current workflow stage : init            transaction details : ISO20022 token            addenda data { ABA routing : xyz }           }                        
Transaction object  307  may encapsulate any suitable standard payment object, such as one storing transaction details in a recognized JSON format. As mentioned, and as illustrated further in  FIG.  6   , transaction objects may also include a current workflow version assigned to the transaction object. Still other metadata may be included, such as a replay tracking count indicating the number of times that the transaction has been subject to replay through one or more steps of the workflow. Transaction details may be immutable, not subject to change while the transaction object is on the streaming data platform, whereas metadata and/or addenda data may be subject to change through additions, removals, updates, and/or other processing or modification by the microservices on transaction exchange platform  320 .
 
     A current workflow stage value may be maintained as part of the transaction metadata in each transaction object. The current workflow stage may indicate which processing steps of the associated workflow have been completed on the transaction. The current workflow stage may indicate the completion status of each respective step of the workflow. As such, in an example implementation the current workflow stage value may be a set of values and/or a data structure indicating the completion of individual workflow steps, e.g. processing by respective microservices. Microservices may be configured to poll the SDP for transactions having a current workflow stage value that indicates completion of each of the pre-requisite steps for processing by the microservice. 
     Microservices on the transaction exchange platform may poll the SDP to identify and retrieve transaction objects having a current workflow stage matching a workflow stage associated with the microservice. Transaction objects matching the microservice&#39;s assigned workflow stage may be processed by the microservice for review, approval, and/or any other suitable processing as part of the overall series of steps required to approve a transaction of the corresponding transaction type. Processing may result in updating one or more elements of the transaction metadata. Once the microservice completes its processing of the transaction object, the microservice can put the transaction object back to the SDP with an updated current workflow stage indicating that the microservice completed its processing. The updated transaction object may then be identified and processed by a next microservice based on the workflow. 
     Turning briefly to  FIGS.  3 B and  3 C ,  FIG.  3 B  illustrates an example structure for a microservice  330 N. The microservice may comprise subcomponents configured to work in concert to apply processing logic associated with a workflow step assigned to the microservice. In the illustrated structure, microservice  330 N comprises a stream listener  3301  which may operate as a standardized way to read from SDP  325  and consume transaction objects that meet the workflow criteria (e.g., stage) associated with microservice  330 N. Microservice  330 N may also include private API  3302 , which may be a RESTful implementation used in synchronous calls supporting singleton integrations into transaction exchange platform  320 , and its use may allow only the response to be exposed to the public API aspect of microservice  330 N. Microservice  330 N may also include core logic  3303 , which may contain the business logic and associated computer instructions to fulfill microservice  330 N&#39;s assigned role in the workflow. Core logic  3303  may be adapted to process transaction objects in accordance with one or more steps of regulatory, security, and/or risk management processes. Microservice  330 N may further include transient data  3304 , which may include a data management layer that deals with data that is attributed to the local functionality of the system, for example truth tables used in processing by core logic  3303 , and persistent data  3307 , which may include a construct to capture state data for the associated workflow stage. Microservice  330 N may further include messaging components  3305  to track message level integrity via natural key encryption derivations of the payment object. And microservice  330 N may include monitoring components  3306 , configured to provide oversight and tracking, and integration components  3308 , configured to provide the ability to integrate with software structure patterns such as Async SDP, SOAP, RESTful API, and the like. As illustrated in  FIG.  3 C , however, a microservice may be made up of a collection of other microservices. For example, as illustrated microservice  331 N comprises component microservices  3321 ,  3322 , and  3323 . 
     Returning to  FIG.  3 A , illustrative transaction exchange platform  320  includes three microservices (microservices  331 ,  332 , and  333 ) configured to operate on ACH transactions. Transaction object  307  is an example ACH transaction, and is added to SDP  325  via API  311 . Transaction object  307  may be added to SDP  325  in an “init” or initialization stage, indicating that none of the workflow steps have yet been completed. In some implementations, the initialization stage may be a separate stage that is marked completed prior to processing by a first microservice, or may be commensurate in scope with a first workflow stage associated with a first microservice of the workflow. In some implementations, the initialization stage for the object may be handled as part of the processing by the APIs  311 ,  313  or otherwise handled alongside workflow processing by the respective microservices. 
     Walking through the example, transaction object  307  may be added to SDP  325  in the initialization stage (stage ‘0’). Microservice  331  may be configured to perform a first step in an approval workflow for transaction having a transaction type of ACH. For example, microservice  331  may be configured to verify that the recipient account of the ACH transaction is valid. Microservice  331  may look for transaction objects on SDP  325  having a first workflow stage (stage ‘1’), for example a stage that indicates initialization pre-processing was completed or, in some implementations, transaction objects in the initialization stage itself. As mentioned above, the current workflow stage of transaction object  307  may indicate each (and/or a subset) of the workflow steps that have been completed on transaction object  307 , and the current workflow stage thus may comprise a data structure listing the completion status of each (and/or a subset) of the workflow steps. Microservice  331  may poll SDP  325  to retrieve transaction objects having a current workflow stage matching (e.g., meeting) the first workflow stage assigned to microservice  331 . In this manner, microservice  331  may extract transaction objects from SDP  325  that have met the criteria for microservice  331  to begin processing. For example, microservice  331  may be configured to wait until initialization steps such as new object snapshotting is completed before performing its processing to verify the recipient account. Transaction objects retrieved by microservice  331  may be removed and/or otherwise blocked on SDP  325  pending processing by microservice  331 . 
     Microservice  331 , having retrieved one or more transaction objects such as transaction object  307 , may perform its corresponding workflow step on the transaction object. The workflow step may comprise suitable processing of the transaction object, such as according to core logic of microservice  331  (similar to core logic  3303  of  FIG.  3 B ). Processing of the transaction object by microservice  331  (or any other microservice) may comprise any of: retrieving the transaction object; reviewing values and other characteristics of the transaction object; interfacing with clearing systems such as clearing systems  215  and/or other systems; comparing values or characteristics to rules, regulations, policies, and the like; adding, removing, updating, or otherwise changing any aspect of the transaction addenda data or transaction metadata; generating reports and/or alerts; presenting the transaction for manual or other review; and/or any other suitable processing associated with the respective step of the workflow for transactions of that type. For example, processing by a microservice may comprise verifying a value of the transaction details, addenda data, and/or transaction metadata against at least one rule. As another example, processing may comprise verifying a value of the transaction details, addenda data, and/or transaction metadata against a watchlist. Processing may comprise determining that the transaction details, addenda data, and/or transaction metadata fail at least one rule; flagging the transaction object for further review; and holding the transaction object in the current workflow stage pending the further review, where updating the current workflow stage of the transaction object to the third workflow stage is based on determining that the further review is completed. Flagging the transaction object for further review may comprise flagging the transaction object for manual review by a user and/or setting the current workflow stage of the transaction object to a current workflow stage associated with another microservice, other than the microservice that typically processes transactions after the first microservice. 
     The processed transaction object may be put back to SDP  325  by microservice  331 , and the current workflow stage of the transaction object may be updated to indicate that microservice  331  has completed its processing. For example, transaction object  307  may be updated to have a current workflow stage of ‘2’ after microservice  331  completes its processing. 
     Back on the SDP  325 , the updated transaction object may be subject to further processing by other microservices in like fashion. For example, microservice  332  may correspond to a second step of processing in the workflow corresponding to ACH transactions, such as a regulatory check associated with anti-money laundering efforts. Microservice  332  may be configured to look for transaction objects having a second current workflow stage, e.g., stage ‘2’, on SDP  325 . Microservice  332  can poll SDP  325  to retrieve such transaction objects and process them according to its own core logic, similarly to that described above with respect to microservice  331 . The processed transaction object may be put back to the SDP  325  with an updated current workflow stage indicating that processing by microservice  332  is completed. Microservice  333  may be configured to look for a third current workflow stage, e.g. stage ‘3’, and may process transaction objects similarly. For example, microservice  333  could perform processing to obligate a customer&#39;s account for the value of the transaction. 
     When the current workflow stage of a transaction object indicates it has completed the steps of the corresponding workflow, the transaction object may be removed from SDP  325  and routed or otherwise made available to other components of the overall transaction system. For example, the approved transaction object, having passed through all steps of the corresponding workflow, may be published to a public streaming data platform  340  accessible outside of the transaction exchange platform. Enterprise systems, applications, users, and others (e.g. enterprise services and users  350 ) may access the completed transaction objects on the public streaming data platform and further process for transaction settlement or other purposes. 
     The structure described herein, where microservices poll SDP  325  for transaction objects having corresponding current workflow stages, may drive payments and other transactions through the system and requisite review and approval workflows. As mentioned, the workflow for a given transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. Workflows may be implemented in the configurations of what workflow stage metadata each microservice is configured to look for on the SDP  325 . However, workflows may also be logically described and/or defined using a directed acyclic graph structure, as described further with respect to  FIG.  4   . 
       FIG.  4    illustrates a sample directed acyclic graph (DAG)  400  that may correspond to a workflow corresponding to transactions having a wire transaction type. The steps of the workflow corresponding to a given transaction type may be organized as a DAG. The DAG may comprise nodes corresponding to the individual steps of the workflow, and edges corresponding to pre-requisite relationships between the steps. The DAG may indicate how transactions from an origination source such as origination  410  flow through the transaction exchange platform  320 , until approval is completed and the transaction is ready for further processing by downstream systems. The DAG may include parallel paths, whereby the transaction object may be subject to concurrent processing by multiple microservices. The DAG may indicate pre-requisite conditions that govern the progression of the transaction object through the stages of the workflow. For example, processing by a microservice in the DAG may be conditioned on the completion of processing by one or more other microservices. The DAG may also indicate branching, conditional paths where a transaction object may be subject to processing by different microservices (and/or different processing generally) based on certain transaction attributes. 
     In the example workflow for wire transactions  400  illustrated in  FIG.  4   , a transaction object added to transaction platform  320  from origination  410  may first enter step ‘A’. Step ‘A’ may correspond to a microservice that performs processing to verify that a recipient account in the transaction details and/or addenda is valid. Once step ‘A’ processing is complete, the workflow proceeds to step ‘B’, which may correspond to a high value thresholder that operates to split transactions for different processing based on their value (also implemented as a microservice). For example, once step ‘A’ is completed and a first microservice updates the current workflow stage of the transaction object, a microservice associated with step ‘B’ may pick up the transaction object and determine if it involves a payment over a certain value, e.g., payments more than $5000. The microservice associated with step ‘B’ may update the transaction object with different current workflow stages depending on whether the transaction should be subject to high value processing (e.g., step ‘C’) or standard processing (e.g., step ‘D’). Step ‘C’ may occur subsequent to step ‘B’ determining that a high value transaction should be subject to enhanced verification, and may comprise performing the enhanced verification by a corresponding microservice. Step ‘D’ may comprise performing standard regulatory verification by a corresponding microservice. Step ‘D’ may also determine if the transaction is an international or domestic wire, and may update the current workflow stage and/or other transaction metadata accordingly. If the transaction is an international wire, it may be routed (by means of the updated transaction metadata) to a microservice associated with step ‘E’, which may perform further international wire processing. If the transaction is a domestic wire, it may proceed to step ‘F’ once regulatory checks are completed. Step ‘F’ may comprise a step to obligate the customer&#39;s account for the amount of the wire, and may be conditioned on successful completion of steps ‘C’, ‘D’, or ‘E’ depending on how the transaction progressed through the workflow. For example, a microservice corresponding to step ‘F’ may be configured to poll SDP  325  for transactions having a current workflow stage that indicates they have completed steps ‘C’, ‘D’, or ‘E’. Finally, completing the workflow step ‘G’ may correspond to a microservice configured to send the wire transaction for settlement, such as to settlement systems  220  of  FIG.  2    or enterprise services and users  350  of  FIG.  3 A . Having completed workflow step G′, the transaction metadata may be updated to indicate completion of the workflow. For example, the current workflow stage of the transaction object may be updated to indicate completion of step ‘G’. As another example, the current workflow stage of the transaction object may reflect the completion of each of steps ‘A’, ‘B’, ‘D’, ‘F’, and ‘G’. 
     Workflow  400  is just one example of a workflow corresponding to a transaction type, and the transaction exchange platform  320  may have many such workflows corresponding to different transaction types. Microservices on transaction exchange platform  320  may be involved in one or more workflows, and may operate on different stages of different workflows. 
     Workflow steps may proceed in parallel, and may be independent of one or more other steps in the workflow. For example, if validating the account number of the sending party and validating the account number of the receiving party were handled by different microservices, the workflow may indicate that both may occur once the transaction is brought onto the platform. However, later steps may be conditioned on the completion of both steps. Either step may occur first in time, depending on the availability of each respective microservice to handle the transaction. 
     Microservices on transaction exchange platform  320  may be automatically configured to look for a corresponding current workflow stage. This automatic configuration may be based on the DAG structure used to logically define the workflow. For example, the individual microservices may be automatically configured to poll SDP  325  for transactions having a current workflow stage that indicates that the pre-requisite criteria represented in the DAG is met prior to processing by the microservice. Each microservice may be configured to look for transaction objects on SDP  325  that have a given workflow type and also have a current workflow stage matching that assigned to the microservice. Thus, microservices may be configured to operate as part of multiple workflows, and can look for transaction objects at different stages of the workflows. As discussed further herein with respect to  FIG.  6   , changes to the DAG may be used to automatically re-configure the microservices to watch for transaction objects in different workflows and/or different workflow stages. 
       FIG.  5    depicts a flowchart illustrating an example method  500  to process transactions by a transaction exchange platform, such as transaction exchange platform  320 . Method  500  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  500 . 
     At step  505 , the system may configure microservices on the transaction exchange platform to watch for transactions of the streaming data platform (SDP) that have transaction metadata indicating that they are in a current workflow stage corresponding to the individual microservice. As discussed above with respect to  FIG.  4   , the system may automatically configure the microservices based on a DAG structure that logically defines the steps of the workflow and their relationships. 
     At step  510 , the system may receive a transaction object and add it to the streaming data platform. The transaction object may be received from a transaction origination source such as origination source  303 , and may be received from an enterprise intermediary service, such as enterprise transaction intermediary service  305 . The transaction object may be received via one or more APIs of the transaction exchange platform, such as APIs  311  and  313  of transaction exchange platform  320 . The transaction object may be added to the SDP in an initialization stage, which may be implemented through setting a current workflow stage of the transaction object&#39;s transaction metadata to an initialization value. The initialization stage may be separate from a first workflow stage associated with a first microservice of the workflow, or could be the same as the first workflow stage. Objects in the initialization stage may be subject to various system processes on the transaction exchange platform, such as format or other verifications, standardization, snapshots, and the like. If the initialization stage is separate from a first workflow stage of the workflow, the transaction object may be updated to have the first workflow stage once initialization processing is completed. 
     The transaction object, on the SDP, may be subject to processing by one or more microservices including first microservice  520  and second microservice  530 . First microservice may be configured to poll the SDP for transactions in a first workflow stage, while second microservice may be configured to poll the SDP for transactions in a second workflow stage. 
     At step  521 , first microservice  520  may poll the SDP for transactions having a particular workflow type (corresponding to a transaction type) and having a first workflow stage within that workflow corresponding to first microservice  520 . The SDP may identify transaction objects that have a current workflow stage value that matches the first workflow stage criteria associated with the first microservice  520 . Identification of matching transaction may be based on transaction metadata indicating a type of workflow, a current workflow stage, and other information associated with the workflow (such as workflow version information, discussed below with respect to  FIG.  6   ). At step  523 , first microservice  520  may retrieve the matching transaction objects for processing. Although steps  521  and  523  are illustrated separately, it will be understood that in practice they may be part of a single contiguous act. 
     At step  525 , first microservice  520  may process the transaction objects it retrieved from the SDP according to processing logic associated with first microservice  520 . Processing a transaction object may include: reviewing, assessing, analyzing, updating, adding to, removing, and/or any other suitable processing of the transaction data, addenda data, and/or transaction metadata associated with the transaction object. 
     At step  527 , first microservice  520  may update a current workflow stage of the transaction object to indicate completion of the processing corresponding to first microservice  520 . In some embodiments, the current workflow stage may be updated to different next step values depending on the processing by first microservice  520 . For example, as discussed with respect to workflow  400  in  FIG.  4   , a microservice may update the current workflow stage of a transaction object to route it to different next microservices depending on whether it meets certain criteria, such as having a value greater than a threshold amount. 
     At step  529 , first microservice  520  may put the updated transaction object back to the SDP. The updated transaction object may have one or more changed values (or none) of its transaction data, addenda data, and/or transaction metadata, in addition to the updated current workflow stage. 
     In the example of method  500 , first microservice  520  may update the current workflow stage of the transaction object to indicate completion of processing by the first microservice  520 . This updated current workflow stage may correspond to the second current workflow stage that second microservice  530  is looking for on the SDP. 
     Thus, at step  531 , the second microservice  530  may poll the SDP for transactions having the second workflow stage and, at step  533 , may retrieve transaction objects matching the second workflow stage. The second microservice  530  may perform similar processing to that described above with respect to first microservice  520 . That is, steps  531 ,  533 ,  535 ,  537 , and  539  may be analogous to steps  521 ,  523 ,  525 ,  527 , and  529 , modified as appropriate for the role assigned to second microservice  530  in the workflow for a given transaction type. The processed, updated transaction object may be put back to the SDP with an updated current workflow stage indicating completion of the processing corresponding to second microservice  530 . 
     At step  540 , the system may determine that the current workflow stage metadata of the transaction object indicates that all requisite processing steps of the workflow have been completed. As a result, processing by the transaction exchange platform may be completed and the approved transaction object may be removed from the SDP and output for further processing and/or settlement. For example, as illustrated in  FIG.  3 A , a completed, approved transaction may be output to a public SDP for access by downstream systems and users. 
     Thus, according to some embodiments a computer-implemented method may receive a transaction object comprising transaction details and transaction metadata. That transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The computer-implemented method may further comprise adding the transaction object to a streaming data platform and updating the current workflow stage of the transaction object to a first workflow stage. A first microservice may poll the streaming data platform to retrieve transactions matching the first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The first microservice may retrieve, from the streaming data platform, the transaction object based on the current workflow stage matching the first workflow stage. The first microservice may process the transaction object. The computer-implemented method may further comprise updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object. A second microservice may poll the streaming data platform to retrieve transactions matching the second workflow stage. The second workflow stage may be associated with the second microservice based on the workflow corresponding to the transaction type. The second microservice may retrieve, from the streaming data platform, the transaction object based on the current workflow stage matching the second workflow stage. The second microservice may process the transaction object. The computer-implemented method may further comprises updating the current workflow stage of the transaction object to a third workflow stage based on completing processing, by the second microservice, of the transaction object; determining that the current workflow stage of the transaction object indicates that the transaction object has completed processing corresponding to the workflow; and removing the transaction object from the streaming data platform and outputting the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow. 
     The first and second microservice may be automatically configured to watch for transactions on the streaming data platform in the first and second workflow stages, respectively, based on the plurality of processing steps. A different second workflow may be associated with a second transaction type and may comprise a different second plurality of processing steps required to approve a given transaction of the second transaction type. The second transaction type may be different from the transaction type. The first microservice may operate on transactions associated with both the workflow and the different second workflow. The plurality of processing steps of the workflow may indicate that the first microservice processes the transaction object at a different stage than the different second plurality of processing steps of the different second workflow. 
     The workflow corresponding to the transaction type may comprise a directed acyclic graph (DAG) indicating the plurality of processing steps required to approve a given transaction of the transaction type. The first and second microservice may be automatically configured to watch for transactions on the streaming data platform in the first and second workflow stages, respectively, based on the DAG. The computer-implemented method may further comprise, responsive to an update to at least one of the plurality of processing steps indicated in the DAG, automatically reconfiguring at least one microservice based on the update. 
     The current workflow stage of the transaction object may comprise a data structure indicating completion status of each respective step of a plurality of processing steps associated with the workflow. The transaction object may be updated to have a current workflow stage corresponding to the second workflow stage based on the current workflow stage indicating that the transaction object has been processed by at least the first microservice and a different third microservice. The first workflow stage and a fourth workflow stage may be independent, such that a third microservice receives the transaction object based on the current workflow stage of the transaction object matching the fourth workflow stage irrespective of whether the first microservice has processed the transaction object. 
     The transaction details may be immutable and may not change while the transaction object is on the streaming data platform. The processing, by the first microservice, of the transaction object may comprise verifying a value of the transaction details, addenda data, and/or transaction metadata against at least one rule. Processing of the transaction object by the first microservice may comprise verifying a value of the transaction details, addenda data, and/or transaction metadata against a watchlist. Processing of the transaction object by the second microservice may comprise determining that the transaction details, addenda data, and/or transaction metadata fail at least one rule, flagging the transaction object for further review, and holding the transaction object in the second workflow stage pending the further review. Updating the current workflow stage of the transaction object to the third workflow stage may be based on determining that the further review is completed. Flagging the transaction object for further review may comprise flagging the transaction object for manual review by a user. Flagging the transaction object for further review may comprise setting the current workflow stage of the transaction object to a fourth workflow stage associated with a third microservice. Updating the current workflow stage of the transaction object to the third workflow stage may be based on determining that processing by the third microservice is completed. 
     As examples, the transaction type of the transaction object may be a wire type transaction. The workflow may comprise a plurality of processing steps required to approve a wire transaction. The transaction type of the transaction object may be an automated clearing house (ACH) type transaction. The workflow may comprise a plurality of processing steps required to approve an ACH transaction. The transaction type of the transaction object may be a cashier check type transaction. The workflow may comprise a plurality of processing steps required to approve a cashier check transaction. The first microservice may process the transaction object to validate a routing number associated with the transaction object. The second microservice may process the transaction object to verify compliance with at least one regulatory requirement associated with the transaction type. The transaction object may be received via an application programming interface (API). 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. The plurality of microservices may comprise at least a first microservice and a second microservice. The first and second microservice may be automatically configured to watch for transactions on the streaming data platform in corresponding workflow stages based on a plurality of workflows corresponding to a plurality of transaction types. The memory may store instructions that, when executed by the at least one processor, cause the platform to receive a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The instructions, when executed by the at least one processor, may further cause the platform to add the transaction object to the streaming data platform; update the current workflow stage of the transaction object to a first workflow stage; and poll, by the first microservice, the streaming data platform to retrieve transactions matching the first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The instructions, when executed by the at least one processor, may further cause the platform to retrieve, by the first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the first workflow stage; process, by the first microservice, the transaction object to add, remove, or update addenda data associated with the transaction object; update the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; and poll, by the second microservice, the streaming data platform to retrieve transactions matching the second workflow stage. The second workflow stage may be associated with the second microservice based on the workflow corresponding to the transaction type. The instructions, when executed by the at least one processor, may further cause the platform to retrieve, by the second microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the second workflow stage; process, by the second microservice, the transaction object; update the current workflow stage of the transaction object to a third workflow stage based on completing processing, by the second microservice, of the transaction object; determine that the current workflow stage of the transaction object indicates that the transaction object has completed processing corresponding to the workflow; and remove the transaction object from the streaming data platform and output the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object, and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; updating the current workflow stage of the transaction object to a first workflow stage; and polling, by a first microservice, the streaming data platform to retrieve transactions matching the first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise retrieving, by the first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the first workflow stage; processing, by the first microservice, the transaction object; and polling, by a second microservice, the streaming data platform to retrieve transactions matching the first workflow stage. The first workflow stage may be also associated with the second microservice based on the workflow corresponding to the transaction type. The steps may further comprise retrieving, by the second microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the first workflow stage; processing, by the second microservice, the transaction object; updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice and the second microservice, of the transaction object; and polling, by a third microservice, the streaming data platform to retrieve transactions matching the second workflow stage. The second workflow stage may be associated with the third microservice based on the workflow corresponding to the transaction type. The steps may further comprise retrieving, by the third microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the second workflow stage; processing, by the third microservice, the transaction object; updating the current workflow stage of the transaction object to a third workflow stage based on completing processing, by the third microservice, of the transaction object; determining that the current workflow stage of the transaction object indicates that the transaction object has completed processing corresponding to the workflow; and removing the transaction object from the streaming data platform and outputting the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow. 
     According to some aspects, a computer-implemented method may comprise steps comprising receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object, and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; and retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise processing, by the first microservice, the transaction object; updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; and retrieving, by a second microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the second workflow stage. The second workflow stage may be associated with the second microservice based on the workflow corresponding to the transaction type. The steps may further comprise processing, by the second microservice, the transaction object; updating the current workflow stage of the transaction object to a third workflow stage based on completing processing, by the second microservice, of the transaction object; determining that the current workflow stage of the transaction object indicates that the transaction object has completed processing corresponding to the workflow; and removing the transaction object from the streaming data platform and outputting the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow. 
     Configurator—Dynamic Microservice Configuration 
     One or more aspects described herein may provide for dynamic reconfiguration of the workflows and/or microservices. For example, a workflow may be modified to change a progression of a transaction object from one microservice to the next. This may be implemented by modifying the configuration of a microservice to look for a different current workflow stage on the streaming data platform. A microservice may be modified to change processing logic and/or any other aspect controlling how the microservice interacts with the streaming data platform and/or transaction objects, or any other aspect of the microservice. For example, processing logic of the microservice may be changed to an updated version to be used in processing future transactions. 
     A configuration interface may generate configuration transaction objects that cause the dynamic reconfiguration of the workflow and/or microservices. Configuration transaction objects may be added to the SDP with a configuration workflow type, and the microservices may retrieve and process the configuration transaction objects. The configuration transaction objects may operate such that a target microservice is reconfigured as a result of processing the configuration transaction object, whether to look for transactions on a different workflow and/or workflow stage, or to modify the processing logic applied to the transactions retrieved by the microservice. 
     As discussed above, each defined workflow on transaction exchange platform  320  may accept a transaction as part of the transaction&#39;s “saga” through the transaction exchange platform. Through the workflow, the transaction may or may not undergo different processing steps, where each step may be provided by one or many microservices or vendor systems. In this way, updating the “saga” that applies to the microservices, integrated vendor systems and datasets, and the entire transaction exchange ecosystem may be akin to an exercise in configuration control. Aspects described herein may allow configurations to be loaded into the transaction exchange platform via the streaming data platform, and may be used to update the entire transaction exchange platform, one or more components of the transaction exchange platform, and/or transactions on the platform. 
     Traditional methods for doing this may require that each element of the workflow be updated, creating exponentially expanding complexity, downtime, and consequently interjecting risk to the transaction exchange ecosystem. Dynamic reconfiguration as described further herein may solve a problem of traditional deployments that interrupt the entire system and require each component to be individually validated. It may also interject a level of control in the deployment by enabling any level of control from the level of remapping the system up to controlling which component gets transactions associated with different versions of the corresponding workflow. Dynamic reconfiguration may also provide control over the system so that configuration can work from the most tactical single transaction (singleton) level up to the entire transaction exchange. Coupled with other tools, such as cloud-based resiliency tools, dynamic reconfiguration may provide a level of flexibility not present in other deployment approaches or solutions to simplifying and/or mitigating the risk of a failed deployment. 
     The transaction exchange may exist in a space that includes numerous legacy, vendor, and future state solutions. Dynamic reconfiguration may provide advantages in supporting partnering with vendors and third parties of any kind as an integration approach can be agreed on and brought into the transaction exchange as a service controlled through dynamic reconfiguration. Once integrated, similarly to the version control described herein, the integration service can be toggled on and off easily through dynamic reconfiguration processes. 
       FIG.  6    illustrates a transaction processing system  600 , similar to that illustrated in  FIG.  3 A  and sharing many like components. However, transaction processing system  600  includes configuration interface  660  to provide dynamic reconfiguration of the workflows and/or microservices. Configuration interface  660  may push configuration transaction objects to SDP  325  to cause re-configuration of a first microservice  631   a  (represented as first version  631   a , which may be updated to second version  631   b ). Due to dynamic reconfiguration, transaction objects may be modified to keep track of the workflow version they should be processed under, as shown by example transaction object  607 . 
     Users managing transaction exchange platform  320  may determine to dynamically reconfigure one or more aspects of the platform, such as by modifying a workflow or causing a new version of a microservice to be deployed. Reconfiguration may be prompted through other processes, such as via a watchdog microservice as discussed further below with respect to  FIG.  9   . Reconfiguration may be done to update and/or improve software processes. Reconfiguration may also be done to address problems that arise during processing, such as when certain systems become unavailable or otherwise encounter problems. Reconfiguration may be done as a new persistent configuration, or could be temporary pending resolution of an issue. The reconfiguration may target any aspect of the platform with desired granularity. For example, the reconfiguration may apply to the entire platform, one or more microservices, and/or one or more transactions, as appropriate. Workflows on transaction exchange platform  320  may also be reconfigured, which may be accomplished through modifying individual microservices to control the workflow type and workflow stages that they watch for. 
     Configuration interface  660  may generate configuration transaction objects that cause the dynamic reconfiguration of the workflow and/or microservices. Configuration transaction objects may be added to the SDP with a configuration workflow type, and the microservices may retrieve and process the configuration transaction objects. Each microservice on transaction exchange platform  320  may be configured to watch for transaction objects having a configuration workflow type (e.g., configuration transaction objects), and may have a corresponding workflow stage similarly to that discussed above with respect to  FIGS.  3 A and  4   . 
     A configuration transaction object may be configured such that, when processed by a microservice, it causes reconfiguration of that microservice. Microservices on the transaction exchange platform  320  may be programmed to process configuration transaction objects and make suitable changes to their parameters based on the processed objects. For example, a microservice may process configuration transaction object comprising instructions to update the workflow assigned to the microservice to a second version of the workflow, e.g., ACH v.  2 , and may update a workflow stage assigned to the microservice. Reconfiguration of microservices can be used to update workflows to new versions, create new workflows, and/or modify existing workflows. Transactions requiring modified processing may be assigned to modified/updated/other workflows to change their assigned processing. 
     Versioning may be used to control processing by appropriate workflows, and may facilitate reliable and accurate record keeping and playback. By tracking which version of a workflow handles a transaction, the transaction can be replayed using the same version at a later time as part of an audit. To this end, microservices may maintain separate indications of each workflow and version handled by the microservice. Transactions may maintain transaction metadata indicating a version value for the workflow applied to the transaction. Transactions may be assigned a current workflow value when added to the transaction exchange platform, and this may be maintained through the life of the transaction. In some circumstances, the version may be changed later and the transaction re-run through the new version of the workflow. 
     Examples of some types of changes that may be implemented through dynamic reconfiguration will be discussed with references to  FIGS.  7 A- 7 C . 
       FIG.  7 A  illustrates pushing a new configuration to one or more of the microservices associated with example workflow  710 , which may correspond to example wire transaction workflow  400 . This new configuration may modify the processing logic applied by one or more of the microservices corresponding to the steps of workflow  400 / 710 . Configuration interface  660  may generate a configuration transaction object comprising the new configuration and push it to the SDP stream. The configuration transaction object may cause update of the microservices mid-stream as part of the flow within the transaction exchange platform on the SDP. Each microservice, as with transaction objects, may be configured to watch for configuration transaction objects associated with a configuration workflow and corresponding workflow stage. The microservices may retrieve matching configuration transaction objects and process them to effect an update to their respective processing logic. A microservice, transaction object, and/or the configuration microservice may maintain a new and prior version of their configurations. This may allow for processing under an appropriate version, and may facilitate a transition between versions as further discussed herein. 
     The mid-stream nature of the dynamic reconfiguration may help avoid significant interruptions and replayability problems posed by prior solutions. As illustrated, transactions  20 ,  30 ,  31 ,  32 , and  33  may be on the SDP and already subject to processing by microservices in the current version of the workflow. When a new configuration is pushed (such as version 6.0), the transactions pending on the SDP may continue to be processed according to the prior version that they started under (e.g., version 5.0). New transactions  34 ,  35 ,  36 , and  37  may be processed under the new version (6.0). As described above, this may be effected through transaction metadata tracking the workflow version associated with the transaction as well as by configuring the microservices to utilize version metadata in retrieving transactions from the SDP. For example, returning to  FIG.  6   , microservice  631   a  may represent a first version of a microservice that looks for transactions in a given workflow type that have a first version value at a corresponding first workflow stage. Microservice  631   b  may represent a second version of the microservice, and may look for transactions in the same workflow type but having a second version value at the same corresponding first workflow stage. In some implementations, the version value may be combined with the workflow type rather than separate (e.g., “ACHv1” and “ACHv2” as separate workflows rather than version values). 
     This procedure, pushing configuration transaction objects via the SDP, may provide additional advantages in that, when new components are added, the configuration interface  660  can interject that new component mid-stream so that it is enabled as a new route without updating the entire transaction exchange. This limits disruption to the local “new” component being added or changed while protecting the entire system for the change. This may be advantageous as change remains one of the single biggest drivers of break events. It also enables on-the-fly updates without taking the entire system down into maintenance. 
       FIG.  7 B  illustrates a dynamic reconfiguration of a workflow process  720 , such as when a component becomes unavailable due to breakage or other adverse events. The dynamic reconfiguration may reconfigure the workflow to bypass problematic services and redirect the workflow to manual review and/or other replacement processing steps. The reconfiguration may avoid bottlenecks associated with microservices earlier in the workflow breaking and preventing transactions from advancing to later microservices. Reconfiguration of workflows may be accomplished through reconfiguring the microservices involved in the workflow to look for different current workflow stages on the SDP. 
     For example, in reconfigured workflow process  720 , which may be a modification of example wire transaction workflow  400 , the dynamic reconfiguration may cause all wire transactions to be subject to the enhanced processing of step ‘C’ rather than the branching paths described above with respect to  FIG.  4   . This may be due to enhanced security concerns, problems with international wire processing, problems at other components, etc. The reconfiguration of  FIG.  7 B  may be accomplished by configuration interface  660  pushing a configuration transaction object to the SDP that is configured to cause the microservices associated with workflow  400 / 720  to modify what workflows and workflow stages they look for, as well as how they update the current workflow once processing is completed. In particular, the modification shown in  FIG.  7 B  could be effected by modifying the microservice associated with step ‘D’ to not pull any transactions, while the microservice affiliated with step ‘C’ may pull all transactions completed by step ‘B’; or step ‘B’ could be modified to update the current workflow of all processed transactions such that they progress to the enhanced verification of step ‘C’, for example. 
     Modifications to the workflow may be done in response to determining conditions that indicate that modified workflow processing should be implemented. The modifications may also be done in response to user changes to a DAG representing the workflow. A user may modify the DAG to define a new workflow/version and the configuration interface  660  may generate a suitable configuration transaction object and push it to the SDP to effect the change. The system may provide a graphical user interface to facilitate users entering modifications to the DAG associated with the workflow processing. 
     Reconfiguration of the workflows and/or microservices may be handled in a versioned manner, such that transactions on the SDP may be handled according to an appropriate and auditable version of the workflow. When a new configuration version is pushed to the SDP for a given workflow, it may be added with a new version value. Transaction objects on the transaction exchange platform may include, as part of their transaction metadata, an indication of a current version value for the workflow at the time they entered the transaction exchange platform. The microservices on the transaction exchange platform may be further configured to identify transaction objects having an appropriate current workflow stages based on the version value of the transaction object. Thus, transactions added under a first workflow version may reliably be processed under the first workflow version, while transaction added after a shift to a second workflow version may be processed using the new, updated workflow version (and associated microservices and processing logic). 
     Thus, a first microservice in a first version  631   a  may be originally configured to watch for transactions associated with the first workflow that have a first version value, while the first microservice in a second version  631   b  may be configured to watch for transactions associated with the first workflow that have a different second version value. Transactions added to the transaction exchange platform may be added having a first version value prior to reconfiguring the first microservice. The first version of the first microservice  631   a  may retrieve transactions matching the first version value in a corresponding workflow/stage. Once a reconfiguration is pushed to the SDP, later transaction added to the SDP may be added having a second version value. The second version of the first microservice  631   b  may retrieve transaction matching the second version value in a corresponding workflow/stage. This may allow for reliable and replayable processing of transactions according to the appropriate version of approval workflows. 
     New workflow versions may be added as illustrated in  FIG.  7 C , through workflow  730 . One flexible use of this approach is the ability to generate a workflow designed to modify an individual transaction and/or group of transactions. Version 1 of the work flow, indicated by the single arrows, may be applied to general transaction objects of a given transaction type. Version 2 of the workflow, indicated by the double arrows, may be applied to problematic transactions subject to modified processing. The transaction exchange platform may support microservices, queuing, and manual workflows as part of being highly resilient, especially around high value workflows. As such, the dynamic configuration aspects may facilitate controlling a single transaction&#39;s path through the platform enabling it to bypass steps normally required by the common workflow. A new workflow can be introduced to the ecosystem with differentiating execution tied directly to a transaction. 
     As an example implementation, the following sample data illustrates how a workflow may change across versions of the workflow according to one or more aspects: 
     Initial Configuration Version 1 
       
     
       
         
           
               
             
               
                   
               
             
            
               
                 { 
               
               
                  “SecurityIdentifier”: “&lt;&lt; identifier &gt;&gt;”, 
               
               
                  “ConfigurationVersion”: “1”, 
               
               
                  “WorkflowStage”: [{ 
               
               
                   “A”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“INIT”] 
               
               
                   }], 
               
               
                   “B”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“A”] 
               
               
                   }], 
               
               
                   “C”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“B”] 
               
               
                   }], 
               
               
                   “E”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“B”] 
               
               
                   }], 
               
               
                   “F”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“C”, “E”] 
               
               
                   }], 
               
               
                   “G”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“F”] 
               
               
                   }] 
               
               
                  }] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     Post Configuration Update Version 2 
       
     
       
         
           
               
             
               
                   
               
             
            
               
                 { 
               
               
                  “SecurityIdentifier”: “&lt;&lt; identifier &gt;&gt;”, 
               
               
                  “ConfigurationVersion”: “2”, 
               
               
                  “WorkflowStage”: [{ 
               
               
                   “A”: [{ 
               
               
                     “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“INIT”] 
               
               
                   “B”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“A”] 
               
               
                   }], 
               
               
                   “D”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“B”] 
               
               
                   }], 
               
               
                   “C”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“D”] 
               
               
                   }], 
               
               
                   “F”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“C”] 
               
               
                   }]; 
               
               
                   “G”: [{ 
               
               
                    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], 
               
               
                    “WorkflowStageCompleted”: [“F”] 
               
               
                   }] 
               
               
                  }] 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     Another aspect of dynamic reconfiguration may provide an event configuration library. Configurations employed to process transactions have certain characteristics may be stored for re-use in other settings, such as when those same characteristics are encountered again. Configurations that were pushed to resolve those transaction may be used again to facilitate handling of other similar transactions. For example, if manual or other review identifies a high risk transaction, a high risk transaction configuration can be pushed to apply a high risk version of the workflow to the high risk transaction. As a particular example, consider when a transaction is associated with a merger of two companies. To facilitate the merger, transactions may be reconfigured to bypass standard workflows and feed through specialized microservices configured to meet specific reporting needs of M&amp;A transactions. 
     These configurations may be utilized manually, automatically, through a hybrid approach, and others. For example, machine learning may be employed to recognize problem situations with transactions. The machine learning system may flag a transaction to be reconfigured to follow a configuration of the configuration library that was previously employed on similar transactions. The system may be designed to self-optimize its own configurations, employing approaches based on features such as shortest path, fastest time, most secure, guaranteed deliver, or any other features desirable to customers. 
       FIG.  8    depicts a flowchart illustrating an example method  800  to dynamically reconfigure a transaction exchange platform, such as transaction exchange platform  320 . Method  800  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  800 . 
     At step  805 , the configuration interface  660  may generate a configuration transaction object. The configuration transaction object may be configured to cause a reconfiguration of the transaction exchange platform, one or more workflows, one or more microservices, and/or one or more transactions. The configuration interface  660  may receive a request to generate the configuration transaction object from a user and/or other system processes, such as a watchdog microservice (discussed further below with respect to  FIG.  9   ). The configuration transaction object may comprise transaction details and transaction metadata. The transaction metadata may indicate that the transaction object has a configuration workflow type and a current workflow stage of the configuration transaction object. In some embodiments, the workflow type of the configuration transaction object is a workflow that is modified by the configuration transaction object, and other aspects of the configuration transaction object indicate to a processing microservice that it includes an update to the processing of the microservice. The configuration transaction object may include instructions that, when processed by the microservice, cause the microservice to be reconfigured. Reconfiguration may include modifying which workflow/version/stage the microservice looks for on the SDP, and/or may include modifying the core processing logic employed by the microservice. 
     At step  810 , the configuration interface  660  may add the configuration transaction object to the SDP, where it may await processing by first microservice  820  and second microservice  830 . 
     The configuration transaction object may be picked up by first microservice  820  and second microservice  830  in a similar fashion to that described above with respect to  FIG.  5   . At steps  821  and  831 , first and second microservices  820  and  830  may poll the SDP to retrieve transactions matching their assigned workflow stages in corresponding workflow types. The configuration transaction objects may have a configuration workflow type, and the microservices may watch for a configuration workflow type object having the workflow stage corresponding to the microservice. At steps  823  and  833 , the microservices may retrieve the configuration transaction object for processing. 
     At steps  825  and  835 , the microservices may process the configuration transaction object when it is in a corresponding workflow stage. Processing the configuration transaction object may cause the microservice to be updated. For example, the configuration transaction object may cause the microservice to update what workflow/version/stage it looks for on the SDP. As another example, processing the configuration transaction object may cause the microservice to update the core processing logic that it applies to transactions. 
     At steps  827  and  837 , the microservices may update the current workflow stage of the configuration transaction object and, at steps  829  and  839 , the microservices may push the updated configuration object back to the SDP. For example, microservice  820  may update the current workflow stage of the configuration object to indicate that microservice  820  has completed processing, and microservice  830  may be configured to look for transaction objects that have a current workflow stage that indicates that microservice  820  completed its processing. 
     At step  840 , the system may determine that the current workflow stage of the configuration transaction object indicates that the processing associated with the configuration workflow has completed, and the configuration transaction object may be removed from the SDP. Notification may be provided to an entity that prompted the reconfiguration that it has been implemented, in some embodiments. 
     Thus, according to some aspects, a computer-implemented method may comprise configuring a plurality of microservices on a streaming data platform to watch for transactions having a corresponding workflow stage associated with a first workflow. The first workflow may correspond to a transaction type and may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise generating a configuration transaction object that may be configured to cause reconfiguration of the first workflow by causing reconfiguration of at least one microservice of the plurality of microservices. The configuration transaction object may comprise transaction metadata that indicates a configuration workflow and a current workflow stage of the configuration transaction object. The steps may further comprise adding the configuration transaction object to the streaming data platform and updating the current workflow stage of the configuration transaction object to a first workflow stage. The method may comprise polling, by a first microservice of the plurality of microservices, the streaming data platform to retrieve transactions matching the first workflow stage; retrieving, by the first microservice and from the streaming data platform, the configuration transaction object based on the current workflow stage matching the first workflow stage; processing, by the first microservice, the configuration transaction object to reconfigure the first microservice; and updating the current workflow stage of the configuration transaction object to a second workflow stage based on completing processing, by the first microservice, of the configuration transaction object. The method may also comprise determining that the current workflow stage of the configuration transaction object indicates that the configuration transaction object has completed processing corresponding to the configuration workflow, and removing the configuration transaction object from the streaming data platform and outputting an indication that the configuration transaction object has completed the processing corresponding to the configuration workflow. 
     Reconfiguring the first microservice may comprise reconfiguring the first microservice to watch for a different second workflow stage. Reconfiguring the first microservice may cause the first microservice to process transaction objects at a different stage of the plurality of processing steps of the first workflow. Reconfiguring the first microservice may comprise reconfiguring the first microservice to modify at least one operation that the first microservice performs on transaction objects associated with the first workflow. Reconfiguring the first microservice may cause removal of at least one second microservice from the first workflow. The first microservice may be originally configured to update completed transactions with a first completed workflow stage. Reconfiguring the first microservice may comprise reconfiguring the first microservice to update completed transactions with a different completed workflow stage. Reconfiguring the first microservice may cause transaction objects to bypass at least one second microservice included in the first workflow. The first microservice may be originally configured to watch for transactions associated with the first workflow that have a first version value. The reconfigured first microservice may be configured to watch for transactions associated with the first workflow that have a different second version value. 
     The method may further comprise adding a first transaction object having a first version value to the streaming data platform prior to reconfiguring the first microservice; retrieving, by the first microservice and from the streaming data platform, the first transaction object based on a current workflow stage of the first transaction matching the first workflow stage; processing, by the first microservice, the first transaction object based on an original configuration of the first microservice based on the first version value; adding a second transaction object having a different second version value to the streaming data platform subsequent to reconfiguring the first microservice; retrieving, by the first microservice and from the streaming data platform, the second transaction object based on a current workflow stage of the second transaction matching the first workflow stage; and processing, by the first microservice, the second transaction object based on the reconfiguration of the first microservice based on the second version value. The steps may further comprise adding a first transaction object to the streaming data platform; determining a current version of the first workflow implemented on the streaming data platform; and updating a version value of the first transaction object based on the current version. The first microservice may process the first transaction object based on an original configuration or a modified configuration based on the version value. 
     The workflow corresponding to the transaction type may comprise a directed acyclic graph (DAG) indicating the plurality of processing steps required to approve a given transaction of the transaction type. The first microservice may be automatically configured to watch for transactions on the streaming data platform in the first workflow stage based on the DAG. Generating the configuration transaction object may be in response to an update to at least one of the plurality of processing steps indicated in the DAG. The steps may further comprise providing a graphical user interface to allow a user to update the at least one of the plurality of processing steps indicated in the DAG. 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. Each microservice of the plurality of microservices may be automatically configured to watch for transactions on the streaming data platform in a corresponding workflow stage based on a plurality of workflows corresponding to a plurality of transaction types. The memory may store instructions that, when executed by the at least one processor, cause the platform to perform steps including configuring the plurality of microservices on the streaming data platform to watch for transactions having a corresponding workflow stage associated with a first workflow. The first workflow may correspond to a transaction type and comprises a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise processing, by a first microservice, transaction objects on the streaming data platform based on the configuration; and generating a configuration transaction object that may be configured to cause reconfiguration of the first workflow by causing reconfiguration of at least one of microservice of the plurality of microservices. The configuration transaction object may comprise transaction metadata that indicates a configuration workflow and a current workflow stage of the configuration transaction object. The steps may further comprise adding the configuration transaction object to the streaming data platform; updating the current workflow stage of the configuration transaction object to a first workflow stage; polling, by a first microservice of the plurality of microservices, the streaming data platform to retrieve transactions matching the first workflow stage; retrieving, by the first microservice and from the streaming data platform, the configuration transaction object based on the current workflow stage matching the first workflow stage; and processing, by the first microservice, the configuration transaction object to reconfigure the first microservice. Subsequent to processing the configuration transaction object, the first microservice may process transaction objects on the streaming data platform based on the reconfiguration. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise configuring a first microservice on a streaming data platform to watch for transactions having a first workflow stage associated with a first workflow corresponding to a transaction type. The first workflow may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise configuring a second microservice on the streaming data platform to watch for transactions having a second workflow stage associated with the first workflow; and generating a configuration transaction object that may be configured to cause reconfiguration of the first workflow by causing reconfiguration of the first microservice and the second microservice. The configuration transaction object may comprise transaction metadata that indicates a configuration workflow, and a current workflow stage of the configuration transaction object. The steps may further comprise adding the configuration transaction object to the streaming data platform; updating the current workflow stage of the configuration transaction object to the first workflow stage; polling, by the first microservice, the streaming data platform to retrieve transactions matching the first workflow stage; retrieving, by the first microservice and from the streaming data platform, the configuration transaction object based on the current workflow stage matching the first workflow stage; processing, by the first microservice, the configuration transaction object to reconfigure the first microservice; updating the current workflow stage of the configuration transaction object to a second workflow stage based on completing processing, by the first microservice, of the configuration transaction object; polling, by the second microservice, the streaming data platform to retrieve transactions matching the second workflow stage; retrieving, by the second microservice and from the streaming data platform, the configuration transaction object based on the current workflow stage matching the second workflow stage; processing, by the second microservice, the configuration transaction object to reconfigure the second microservice; updating the current workflow stage of the configuration transaction object to a third workflow stage based on completing processing, by the second microservice, of the transaction object; determining that the current workflow stage of the configuration transaction object indicates that the configuration transaction object has completed processing corresponding to the configuration workflow; and removing the configuration transaction object from the streaming data platform and outputting an indication that the configuration transaction object has completed the processing corresponding to the configuration workflow. 
     According to some aspects, a computer-implemented method may comprise steps comprising configuring a plurality of microservices on a streaming data platform to watch for transactions having a corresponding workflow stage associated with a first workflow. The first workflow may correspond to a transaction type and comprises a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise generating a configuration transaction object that may be configured to cause reconfiguration of the first workflow by causing reconfiguration of at least one microservice of the plurality of microservices. The configuration transaction object may comprise transaction metadata that indicates: a configuration workflow, and a current workflow stage of the configuration transaction object. The steps may further comprise adding the configuration transaction object to the streaming data platform; retrieving, by a first microservice and from the streaming data platform, the configuration transaction object based on the current workflow stage matching a first workflow stage associated with the first microservice; processing, by the first microservice, the configuration transaction object to reconfigure the first microservice; and updating the current workflow stage of the configuration transaction object to a second workflow stage based on completing processing, by the first microservice, of the configuration transaction object. 
     Chronos—Snapshot Microservice and Transaction Replay 
     Some aspects described herein may provide a snapshot microservice on the transaction exchange platform, configured to maintain a record of the data values of each transaction object as they progress through the corresponding workflows. “Snapshot,” when used to refer to the snapshot microservice, may refer to the functionality of the snapshot microservice to track a transaction object&#39;s data values and each of its changed states as an archival service. The snapshot microservice thus may also be referred to as a payment transaction object changed state archive, or Chronos. The snapshot microservice may create a snapshot record for new transaction objects and store a copy of the data of the transaction object. As the transaction object progresses through the workflow and is processed by the other microservices, the snapshot microservice can identify transaction objects that have their data changed. The snapshot microservice can retrieve the changed objects and store snapshot data tracking the change of the transaction object. 
       FIG.  9    illustrates a transaction processing system  900  that may be similar to transaction processing systems  300  and/or  600  of  FIGS.  3 A and  6   . Transaction processing system  900  may add, relative to systems  300  and  600 , snapshot microservice  970  and watchdog microservice  980 . This document section focuses on snapshot microservice  970 , while the next document section focuses on watchdog microservice  980 . 
     Snapshot microservice  970  may operate on transaction exchange platform  320  to maintain a record of the data values of each transaction object on the streaming data platform, and may track how the transaction objects change during processing on the platform. Snapshot data may be stored in snapshot database  975 , which may comprise on-disk storage capable of effectively storing large volumes of data. Snapshot microservice  970  and snapshot database  975  may be configured to store differential snapshots of a transaction object. Snapshot microservice  970  may store an original state of a transaction object when it is added to the SDP, and may store information indicating each subsequent change to the transaction object. Snapshot microservice may track data values associated with each of the transaction details, transaction addenda data, and/or transaction metadata. In some embodiments however, the transaction metadata may be additionally and/or alternatively tracked by watchdog microservice  980 . 
     The snapshot microservice  970  may be configured to identify and retrieve transaction objects added to SDP  325  in an initialization stage. Transaction objects may be added to the SDP  325  in an “init” or initialization stage, indicating that none of the workflow steps have yet been completed. In some implementations, the initialization stage may be a separate stage that is marked completed prior to processing by a first microservice  331 , or may be commensurate in scope with a first workflow stage associated with a first microservice  331  of the workflow. In some implementations, the initialization stage for the object may be handled as part of the processing by the APIs  311 ,  313  that receive transactions to be added to the SDP  325 , or otherwise handled alongside workflow processing by the respective microservices  331 ,  332 , and  333 . 
     Snapshot microservice  970  may store an initial snapshot of a transaction object in the initialization stage, then update a current workflow stage of the transaction object to indicate that the initialization processing has completed. This may comprise updating the current workflow stage of the transaction object to match a first workflow stage associated with microservice  331 , which microservice  331  performs the first step of the workflow. Alternatively, snapshot microservice  970  may treat transaction objects in the first workflow stage as being subject to initialization (as new objects), and may determine that an initial, new snapshot should be recorded in snapshot database  975 . 
     Snapshot microservice  970  may be configured to poll the SDP to retrieve all transaction objects having changed data. In some embodiments, this may comprise retrieving all transaction objects and determining whether there have been any changes. In other embodiments, it may comprise retrieving specifically the transaction objects that have changed, whether based on determining that the data has changed or merely that a workflow stage has advanced. Snapshot microservice  970  may determine a difference in the changed transaction object and store snapshot information indicating the difference. The snapshot information may include metadata such as an associated timestamp, workflow stage, and/or any other suitable metadata to facilitate audit and potential rollback of the transaction object and workflow processing. 
     These snapshots of the transaction object may be used to correct processing errors in the approval workflow, as a transaction object may have its data reverted back to an earlier state and its workflow stage reverted to an earlier stage. In this way, the transaction object may be made to repeat an earlier step of the workflow and be subject to re-processing by a corresponding microservice (or, in some cases such as repeated failures, a human operator). The snapshot microservice  970  may regenerate a transaction object using the snapshot data corresponding to the transaction object from an earlier time, prior to a point in processing that is subject to the rewind. In effect, snapshot microservice  970  may roll back the values of the transaction object to an earlier point in time. Then, the regenerated transaction object may be put back on SDP  325  and will be picked up for re-processing by the earlier microservice. For example, if an error is determined to have occurred during processing of transaction object  307  by first microservice  331 , the snapshot microservice  970  may revert transaction object  307  to state prior to processing by first microservice  331 . The first microservice  331  would have updated the stage of the transaction object  307  to the second workflow stage when processing completed. The snapshot microservice  970  may revert the current workflow stage of the transaction object  307  to the first workflow stage, so that when the transaction object  307  is pushed back to the SDP  325  it will be picked up for processing again by the first microservice  331 . 
     A command to replay a transaction may be received by the snapshot microservice  970 . For example, watchdog microservice  980  may determine that processing by first microservice  331  completed abnormally, and may command snapshot microservice  970  to perform a replay. Other conditions may prompt a replay, such as an error state of a microservice or the transaction exchange platform  320 . 
     The snapshot microservice may track the total number of times that a transaction object is reverted/replayed on one or more microservices, and may flag a transaction as presenting problems requiring manual or other review when the number of replays exceeds a transaction or based on other criteria. Replaying a transaction may cause update of a transaction replay count associated with the transaction, which may be stored as part of the transaction object&#39;s transaction metadata and/or as part of the snapshot information. If a threshold number of replays take place, for example a configurable maximum of 3 replays at a single stage of the workflow, the snapshot microservice  970  may flag the transaction as having failed and/or requiring further review. The maximum, which may be implemented as a threshold value, may be configured by a user and/or may be automatically configured by system processes based on historical data, current system state, and other performance metrics. The transaction may be held in a workflow stage corresponding to the microservice where processing failed, in some instance. In other instances, a failed transaction may be routed to additional processing, such as by a different workflow and/or other parts of the same workflow, where it may be processed by other microservices. 
     When a replay occurs, the snapshot information may continue to track all subsequent events as well as all events that had occurred already on the transaction, even if they are subject to rewinding. Thus, the snapshot information may support a comparison during troubleshooting to assess which parts of the system led to errors in the workflow. This information may be archived to assist in troubleshooting and audits. Snapshot information related to error processing that is fixed via replay may be deleted upon successful completion of the re-attempt. 
     The snapshot data may also support audit of the transactions, offering a complete picture of how the transaction object changed while on the transaction exchange platform. If desired as part of auditing results, the snapshot microservice  970  may replay an entire transaction snapshot by snapshot. This may be done in support of an audit or for troubleshooting and analysis. 
       FIG.  10    depicts a flowchart illustrating an example method  1000  to generate snapshot information tracking a transaction object on a transaction exchange platform, such as transaction exchange platform  320 . Method  1000  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1000 . 
     At step  1005 , the transaction exchange platform may receive a transaction object and add it to a SDP. The transaction object may be added to the SDP in an initialization stage. 
     At step  1031 , snapshot microservice  1030  may store an initial snapshot record for new transaction objects on the SDP. For example, snapshot microservice  1030  may poll the SDP for transaction objects in the initialization stage. Alternatively and/or additionally, snapshot microservice  1030  may poll SDP for all transaction objects, and determine which are new and should be stored as initial snapshot records. 
     At step  1033 , snapshot microservice  1030  may update the current workflow stage of the transaction object to indicate completion of initialization processing by the snapshot microservice  1030 . This may comprise updating the current workflow stage of the transaction object to be a workflow stage associated with a workflow microservice  1020 . At step  1035 , snapshot microservice  1030  may put the transaction object back to the SDP with the updated current workflow stage. 
     At step  1021 , workflow microservice  1020  may poll the SDP for transactions having a current workflow stage assigned to the microservice, and at step  1023  the workflow microservice may retrieve the matching transaction objects. At step  1025 , workflow microservice  1020  may process the transaction objects according to its respective processing logic, which may include updating, adding, removing, and/or otherwise changing values of the transaction details, addenda data, and/or transaction metadata associated with the transaction object. At step  1027 , workflow microservice  1020  may update the transaction object&#39;s current workflow stage to indicate completion of processing by microservice  1020  and, at step  1029 , put the updated transaction object back to the SDP. 
     At step  1037 , snapshot microservice  1030  may poll the SDP for transactions and, at step  1039 , determine transaction having changed data. Snapshot microservice  1030 , at step  1041 , may record snapshot data corresponding to the changed data as a result of processing by workflow microservices  1020 . The snapshot microservice  1030  may, at step  1043 , put the transaction object back to the SDP for further processing by workflow microservices  1020 . 
       FIG.  11    depicts a flowchart illustrating an example method  1100  to replay a transaction (e.g., subject it to reprocessing) using a snapshot microservice on a transaction exchange platform, such as transaction exchange platform  320 . Method  1100  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1100 . 
     At step  1105 , the transaction exchange platform may receive a transaction object and add it to a SDP. The transaction object may be added to the SDP in an initialization stage. 
     The transaction object may be processed by microservice  1120  in steps  1121 ,  1123 ,  1125 ,  1127 , and  1129  as described herein, for example in similar fashion to that described with respect to  FIG.  10    in steps  1021 ,  1023 ,  1025 ,  1027 , and  1029 . 
     Snapshot microservice  1130  may record initial and changed snapshot information in steps  1131  and  1131 , as described in greater detail above with respect to  FIG.  10    in steps  1031 ,  1033 ,  1035 ,  1037 ,  1039 ,  1041 , and  1043 . 
     At step  1135 , snapshot microservice  1130  may receive a command to replay a workflow step for a transaction object. For example, a watchdog microservice may send snapshot microservice  1130  a command to replay the transaction object in a first workflow stage. 
     At step  1137 , snapshot microservice  1130  may use the stored snapshot information to rollback the transaction object to its state prior to the point of replay. The transaction object may be made to repeat an earlier step of the workflow and be subject to re-processing by a microservice to the workflow step indicated to be replayed. The snapshot microservice  1130  may regenerate a transaction object using the snapshot data corresponding to the transaction object from an earlier time, prior to a point in processing that is subject to the rewind. 
     At step  1139 , snapshot microservice  1130  may put the regenerated transaction object back on the SDP. Because the regenerated transaction object has the earlier workflow stage, it will be picked up for re-processing by the earlier microservice. 
     Thus, according to some aspects, a computer-implemented method may comprise steps comprising receiving a transaction object comprising transaction details, addenda data, and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object, and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform. Adding the transaction object to the streaming data platform may comprise setting the current workflow stage of the transaction object to an initialization stage. The steps may further comprise polling, by a snapshot microservice, the streaming data platform to retrieve transactions matching the initialization stage. The initialization stage may be associated with the snapshot microservice. The steps may further comprise retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the transaction object; and updating the current workflow stage of the transaction object to a next workflow stage based on completing storing, by the snapshot microservice, the snapshot data corresponding to the transaction object. The method may comprise retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise processing, by the first microservice, the transaction object to modify the addenda data. The method may comprise determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with the addenda data of the transaction object has changed after the transaction object has left the initialization stage, and storing, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data. 
     Determining that the at least one value associated with the addenda data of the transaction object has changed may comprise retrieving, by the snapshot microservice and from the streaming data platform, the transaction object. The steps may further comprise determining that the processing, by the first microservice, of the transaction object did not complete successfully, and causing the first microservice to repeat processing of the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice. Causing the first microservice to repeat processing of the transaction object may comprise regenerating, by the snapshot microservice, the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice, and returning the regenerated transaction object to the streaming data platform. The current workflow stage of the regenerated transaction object may be set to the first workflow stage. The steps may further comprise determining a number of times that the transaction object has undergone processing by the first microservice and, in response to determining that the number of times that the transaction object has undergone processing by the first microservice exceeds a threshold value, rejecting the transaction object as having failed processing associated with the first microservice. The steps may further comprise flagging the transaction object for further review based on rejecting the transaction and holding the transaction object in the first workflow stage pending the further review. Updating the current workflow stage of the transaction object to a second workflow stage may be based on determining that the further review is completed. Flagging the transaction object for further review may comprise flagging the transaction object for manual review by a user. Flagging the transaction object for further review may comprise causing the transaction object to be processed by a third microservice. Updating the current workflow stage of the transaction object to the second workflow stage may be based on determining that processing by the third microservice is completed. The snapshot microservice may record second snapshot data corresponding to the transaction object from prior to causing the first microservice to repeat processing of the transaction object. The second snapshot data may be maintained despite the repeat processing of the transaction object. 
     The steps may further comprise determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with the transaction metadata has changed; retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on determining that the at least one value has changed; and storing, by the snapshot microservice, data corresponding to the changed at least one value associated with the transaction metadata. The next workflow stage may correspond to the first workflow stage associated with the first microservice. The initialization stage may correspond to the first workflow stage. The snapshot microservice may generate a transaction history for the transaction object. The snapshot microservice may generate a transaction history for each transaction object added to the streaming data platform. The snapshot microservice may store snapshot data in an on-disk database. 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. Each microservice of the plurality of microservices may be configured to watch for transactions on the streaming data platform in a corresponding workflow stage based on a plurality of workflows corresponding to a plurality of transaction types. The memory may store instructions that, when executed by the at least one processor, cause the platform to perform steps including receiving a transaction object comprising transaction details, addenda data, and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform. Adding the transaction object to the streaming data platform may comprise setting the current workflow stage of the transaction object to an initialization stage. The steps may further comprise polling, by a snapshot microservice, the streaming data platform to retrieve transactions matching the initialization stage. The initialization stage may be associated with the snapshot microservice. The steps may further comprise retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; and storing, by the snapshot microservice, snapshot data corresponding to the transaction object, updating the current workflow stage of the transaction object to a next workflow stage based on completing storing, by the snapshot microservice, the snapshot data corresponding to the transaction object; and retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise processing, by the first microservice, the transaction object to modify the addenda data; determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with the addenda data of the transaction object has changed after the transaction object has left the initialization stage; and storing, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data. 
     The steps may further comprise determining that the processing, by the first microservice, of the transaction object did not complete successfully; and causing the first microservice to repeat processing of the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice. Causing the first microservice to repeat processing of the transaction object may comprise causing the transaction exchange platform to regenerate, by the snapshot microservice, the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice; and return the regenerated transaction object to the streaming data platform. A current workflow stage of the regenerated transaction object may be set to the first workflow stage. The snapshot microservice may generate a transaction history for each transaction object added to the streaming data platform. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise receiving a transaction object comprising transaction details, addenda data, and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object, and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform. Adding the transaction object to the streaming data platform may comprise setting the current workflow stage of the transaction object to an initialization stage. The steps may further comprise polling, by a snapshot microservice, the streaming data platform to retrieve transactions matching the initialization stage. The initialization stage may be associated with the snapshot microservice. The steps may further comprise retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; and storing, by the snapshot microservice, snapshot data corresponding to the transaction object, updating the current workflow stage of the transaction object to a next workflow stage based on completing storing, by the snapshot microservice, the snapshot data corresponding to the transaction object; and retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise processing, by the first microservice, the transaction object to modify the addenda data; determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with the addenda data of the transaction object has changed after the transaction object has left the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data; determining that the processing, by the first microservice, of the transaction object did not complete successfully; and causing the first microservice to repeat processing of the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice. Causing the first microservice to repeat processing of the transaction object may comprise regenerating, by the snapshot microservice, the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice; and returning the regenerated transaction object to the streaming data platform. A current workflow stage of the regenerated transaction object may be set to the first workflow stage. 
     Arbiter—Watchdog Microservice for Tracking, Monitoring, and Remediation 
     Some aspects described herein may provide a watchdog microservice on the transaction exchange platform, configured to track the progress of transaction objects through their respective workflows. “Watchdog,” when referring to the watchdog microservice, may refer to the functionality of the watchdog microservice to observe and archive the progress of transaction objects on the transaction exchange platform, and enforce the associated workflows. Thus the watchdog microservice may also be referred to as an observability and archive microservice, or Arbiter. The watchdog microservice may determine that a transaction object has completed the approval workflow based on the transaction object completing each component step of the workflow, and may cause the completed transaction to be output from the transaction exchange platform. The watchdog microservice may also enforce the workflow, causing transactions to repeat and/or revisit problematic steps of the workflow. 
     The watchdog microservice may track metrics and/or other statistics associated with the workflows, microservices, and/or transactions. Based on the tracked workflow data, the watchdog microservice may be able to assess trends associated with a workflow, microservice, or transaction. The watchdog microservice may compare a metric and/or other statistic to threshold performance values to determine when the workflow, microservice, or transaction is subject to abnormal or undesirable performance complications. For example, the watchdog microservice could determine that a particular microservice has a current average processing time greater than a configured warning threshold, or outside a typical range. Based on detecting abnormal or undesirable performance of the workflow, microservice, or transaction, the watchdog microservice can generate and/or implement a recommended corrective action. Example corrective actions may include causing a transaction to be replayed via a snapshot microservice, and causing a workflow to be dynamically reconfigured using a configuration interface. 
       FIG.  9   , discussed above with respect to the snapshot microservice, also depicts watchdog microservice  980  and watchdog database  985 . Watchdog microservice  980  may generate workflow tracking records for each transaction object on the transaction exchange platform  320 , and may store information indicating whether the transaction object completed each step of the workflow along with timestamps and other suitable metadata. The workflow tracking records may be stored in watchdog database  985 , which may comprise an in-memory database configured to support quick access and retrieval of records while on SDP  325 . 
     The watchdog microservice  980  may serve as the judge (arbiter) in determining when a transaction object has completed the workflow processing steps of its corresponding workflow. This is further described with respect to  FIG.  12   . 
       FIG.  12    depicts a flowchart illustrating an example method  1200  to track workflow progress and determine if a transaction has completed the workflow on a transaction exchange platform, such as transaction exchange platform  320 . Method  1200  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1200 . 
     At step  1205 , the transaction exchange platform may receive a transaction object and add it to a SDP. The transaction object may be added to the SDP in an initialization stage. 
     At step  1231 , watchdog microservice  1230  may store an initial record for new transaction objects on the SDP. Watchdog microservice  1230  may identify new transactions on the SDP, potentially as a result of the initialization stage, and may generate new workflow tracking records for the new transaction objects. Watchdog microservice  1230  may poll the SDP to retrieve new transactions as they are added. Additionally and/or alternatively, watchdog microservice  1230  may poll the SDP to retrieve all new transactions and determine which are new, as shown in step  1233 . 
     Workflow microservices  1220  may process transaction objects on the SDP in the manners described above in detail. For example, illustrated steps  1221 ,  1223 ,  1225 ,  1227 , and  1229  may correspond to steps  1021 ,  1023 ,  1025 ,  1027 , and  1029  of  FIG.  10   . 
     At step  1233 , watchdog microservice  1230  may poll the SDP for transactions and, at step  1235 , determine transaction objects having a changed workflow stage. In some embodiments, watchdog microservice  1230  may poll all transactions and determine which have changes. In other embodiments, watchdog microservice  1230  may poll the SDP to request transaction that have changed. 
     At step  1237 , watchdog microservice  1230  may record workflow tracking data corresponding to the change in the workflow stage of the transaction object. For example, watchdog microservice  1230  may update a workflow tracking record associated with the transaction object to indicate it completed a workflow stage associated with a workflow microservice  1220 . The watchdog microservice  1230  may further store other metadata regarding the updated workflow stage, including a timestamp of the recorded change. 
     At step  1239 , the watchdog microservice  1230  may determine whether the current workflow stage of the transaction object (and/or the workflow tracking data) indicate that the transaction object has met the requisite steps of the workflow associated with the transaction type of the transaction objects. For example, the watchdog microservice  1230  may assess whether the current workflow stage information of the transaction metadata indicates completion of a series of steps that satisfy the criteria of the workflow associated with a particular transaction type of the transaction object. 
     At step  1241 , the watchdog microservice  1230  may determine that the workflow is not complete, and may proceed to step  1245  where the transaction object is put back to the SDP after recording the workflow tracking information. 
     If, at step  1241 , the watchdog microservice  1230  determines that the workflow is complete, processing may proceed to step  1243  where the transaction object is removed from the SDP of the transaction exchange platform and output as completed. For example, the transaction object may be updated with an indication that it completed the workflow and is approved, and may be put to a public SDP  340  accessible to enterprise systems and users  350 . 
     Additionally and/or alternatively to the workflow completion determinations described above, the watchdog microservice  980 / 1230  may enforce the individual steps of the workflow. The watchdog microservice may assess whether a current workflow stage indicates a valid workflow stage under the restrictions of the workflow structure. If the current workflow stage of the transaction object is not valid, the watchdog microservice may cause the transaction object to be processed by one or more appropriate microservices associated with the workflow, thereby enforcing the workflow. Working in conjunction with the snapshot microservice, the watchdog microservice may cause a transaction to repeat a step of the workflow by reverting the transaction object to an earlier state in response to detecting problems. 
     According to some aspects, the watchdog microservice may track metrics and/or other statistics associated with the workflows, microservices, and/or transactions. Based on the tracked workflow data, the watchdog microservice may be able to assess trends associated with a workflow, microservice, or transaction. The watchdog microservice may compare a metric and/or other statistic to threshold performance values to determine when the workflow, microservice, or transaction is subject to abnormal or undesirable performance complications. This is described further below with respect to  FIG.  13   . 
       FIG.  13    depicts a flowchart illustrating an example method  1300  to track workflow progress and recommend corrective action based on performance metrics on a transaction exchange platform, such as transaction exchange platform  320 . Examples of performance metrics include, for example, how long it takes a transaction to complete an associated workflow from start to finish. As will be discussed, performance metrics may be measured at any suitable level, for example per transaction, per group of transaction, within a time frame, within a sample, and the like. Method  1300  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1300 . 
     At step  1305 , the transaction exchange platform may receive a transaction object and add it to a SDP. The transaction object may be added to the SDP in an initialization stage. 
     At step  1310 , the watchdog microservice may track progress of transaction objects on the SDP through the microservices and workflows associated with a transaction type of the transaction object, as described above with respect to  FIG.  12   . 
     At step  1315 , the watchdog microservice may determine one or more performance metrics associated with the transaction exchange platform, one or more workflows, one or more microservices, types of transactions, groups of transactions, individual transactions, and/or any suitable granularity. The watchdog microservice may record how long it takes a transaction to move through its corresponding workflow, from microservice to microservice. This time may be recorded against upper and/or lower control limits with a rolling time period. The time period may be taken into account and normalized against business cycles (for example: weekends are different than work days and certain hours of the work day look very different). Other metrics may be considered besides processing time, such as throughput (volume), error rates, approve/deny rates, paths taken in branching workflows, and/or any other suitable metric. 
     Metrics may be tracked at any desired level of granularity. For example, the watchdog microservice may track how long transaction take to progress through the ACH workflow, and may assess whether this is within historical performance ranges. Similarly, the watchdog microservice may track how long a particular microservice takes to process transactions over the last five minutes and determine when this rises above a warning level, which may indicate a problem with the microservice. The watchdog microservice may determine baseline performance metrics for the transaction exchange platform, workflows, microservices, and the like. Current metrics may be compared to these baseline metrics to determine and address abnormal performance. 
     At step  1320 , the watchdog microservice may determine at least one recommended action based on the performance metrics. Many corrective actions may be recommended by the watchdog microservice, which may flexibly adapt and learn suitable processes for responding to abnormal system conditions. A common recommended corrective action may be to command replay of an earlier workflow stage for a transaction or group of transactions. Working with the snapshot microservice, the watchdog microservice can cause a transaction object to revert to an earlier state, where the reversion to the current workflow stage of the transaction object would cause it to be processed again by an appropriate microservice. Where a particular microservice is showing performance abnormalities across a range of transactions, the watchdog microservice may determine that the particular microservice is having problems and recommend a suitable corrective action. As an example, the watchdog microservice may determine that a dynamic reconfiguration to implement alternate processing workflows, addressing the issues presented by the particular microservice, represents a suitable corrective action. The watchdog microservice may coordinate with the configuration interface to affect a reconfiguration of the workflow and the corresponding microservices, potentially temporarily. In some implementations, dynamic reconfiguration of a workflow, microservice, or transaction may be recommended and implemented once successive replays through the snapshot microservice have failed. Such reconfiguration may address patterns of failure that become apparent from repeat errors from the microservices/workflows. 
     The watchdog microservice may implement other corrective actions as well. For example, the watchdog microservice may utilize machine learning techniques to self-optimize the workflows based on any suitable feature, such as enhancing actions (rather than corrective action), security lockdown against intrusions, speed throughput, prioritized routing, restart, and most any other incident, administrative, or management handling. The watchdog microservice provides a useful interface and allows machine learning collector agents to be deployed on the transaction exchange platform to gather system state information for use in optimizing and managing the transaction exchange platform. Other metrics in addition to performance, security, resiliency, responsiveness, robustness, visiblity, etc. may be considered by the watchdog microservice, and the flexibility and comprehensive scope of the watchdog microservices may enable powerful management of the transaction exchange platform. 
     At step  1325 , the watchdog microservice may cause the recommended action to be implemented. For example, the watchdog microservice may command the snapshot microservice to replay a workflow stage for the transaction object. As another example, the watchdog microservice may command the configuration interface to dynamically reconfigure one or more workflows and/or microservices based on the performance metric. 
     Subsequent to implementing the corrective action, the watchdog microservice may determine that successful processing is completed in step  1330 . Or the watchdog microservice may determine that processing has failed in step  1340 , and may output the transaction for further review (manually and/or automatically), and may generate another recommended action, at step  1345 . 
     According to some aspects, and as discussed above, the watchdog microservice may recommend as a corrective action replay of an earlier workflow stage for a transaction or group of transactions. Working with the snapshot microservice, the watchdog microservice can cause a transaction object to revert to an earlier state, where the reversion to the current workflow stage of the transaction object would cause it to be processed again by an appropriate microservice. This is described further below with respect to  FIG.  14   . 
       FIG.  14    depicts a flowchart illustrating an example method  1400  to track performance metrics and determine to replay a transaction on a transaction exchange platform, such as transaction exchange platform  320 . Method  1400  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1400 .  FIG.  14    may combine aspects of  FIGS.  11  and  13   , as explained further below. 
     At step  1405 , the transaction exchange platform may receive a transaction object and add it to a SDP. The transaction object may be added to the SDP in an initialization stage. At step  1421 , watchdog microservice  1420  may track program on the SDP of transaction objects through microservice and workflows, as described with respect to  FIG.  12    above. 
     At step  1423 , watchdog microservice  1420  may determine that a transaction object should replay a workflow stage. For example, as discussed above with respect to  FIG.  13   , the watchdog microservice may determine that a transaction object did not correctly complete the workflow step and/or that the microservice associated with the step is experiencing abnormal performance issues. At step  1425 , the watchdog microservice  1420  may command snapshot microservice  1430  to replay the transaction object at the earlier workflow stage. 
     Snapshot microservice  1430  may store snapshot data records for transaction objects on the SDP in steps  1431  and  1433 , as discussed above in  FIGS.  10  and  11   . At step  1435 , snapshot microservice  1430  may receive the command to replay the workflow step for the transaction object from the watchdog microservice  1420 . Snapshot microservice may rollback the transaction object and reinject it to the SDP at steps  1437  and  1439 , in the manner described above with respect to  FIG.  11   . 
     At step  1441 , watchdog microservice  1420  may determine if the replayed workflow stage was processed successfully. If it processed successful, processing may proceed to step  1443  where the transaction workflow continues. 
     If, at step  1441 , watchdog microservice  1420  determines that processing did not complete successfully, watchdog microservice  1420  may determine whether a maximum number of rollbacks have been attempted at step  1445 . The snapshot microservice  1430  and/or watchdog microservice  1420  may maintain a counter of the number of rollback/replay attempts. The number of rollback/replay attempts is less than a configurable threshold, then processing may return to step  1425  where watchdog microservice  1420  again commands snapshot microservice  1430  to replay the transaction. 
     If, at step  1445 , watchdog microservice  1420  determines that a maximum number of replay attempts have already occurred, then watchdog microservice may determine a failure of the transaction to progress through the workflow stage at step  1447 . At step  1449  the watchdog microservice  1420  may determine a further recommended action, such as triggering a dynamic reconfiguration of the work follow. This is shown further in  FIG.  15   . 
       FIG.  15    depicts a flowchart illustrating an example method  1500  to track performance metrics and determine to replay a transaction on a transaction exchange platform, such as transaction exchange platform  320 . Method  1500  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1500 .  FIG.  15    may combine aspects of  FIGS.  11 - 14   , as explained further below. 
     At step  1505 , the transaction exchange platform may receive a transaction object and add it to a SDP. The transaction object may be added to the SDP in an initialization stage. At step  1521 , watchdog microservice  1520  may track program on the SDP of transaction objects through microservice and workflows, as described with respect to  FIG.  12    above. 
     At step  1522 , the watchdog microservice may determine that a transaction object should have a particular workflow stage replayed, and may order the snapshot microservice to replay the transaction as described in  FIG.  14   . Step  1522  may be optional, as watchdog microservice  1520  may determine to command dynamic reconfiguration even in the absence of a replayed transaction. 
     At step  1523 , the watchdog microservice may determine that the transaction exchange platform, one or more workflows, one or more microservices, or any other component should be modified. As discussed further above with respect to  FIG.  13   , the watchdog microservice may make this determination based on tracking one or more performance metrics associated with the transaction exchange platform and/or any of its components. 
     At step  1525 , the watchdog microservice  1520  may command the configuration interface  1530  to reconfigure one or more microservices (and/or workflows, and/or any other component of the transaction exchange platform). 
     At step  1531 , configuration interface  1530  may receive the command to reconfigure the microservices of the workflow, and may proceed through steps  1533  and  1535  to generate a configuration transaction object that is pushed to the SDP to affect the desired reconfiguration, as described above with respect to  FIG.  8   . 
     At step  1527 , the watchdog microservice  1520  may command the snapshot microservice to replay the transaction object using the reconfigured workflow, if a particular transaction and/or group of transactions were subject to erroneous and/or failed processing on the original configuration. 
     At step  1529 , the watchdog microservice  1520  may evaluate performance of the reconfigured workflow and continue to evaluate performance metrics associated with aspects of the transaction exchange platform. 
     Thus, according to some aspects, a computer-implemented method may comprise receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object, and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform and retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise processing, by the first microservice, the transaction object and updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object. In response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed, the method may comprise: retrieving, by the watchdog microservice and from the streaming data platform, the transaction object based on determining that the current workflow stage has changed and storing, by the watchdog microservice, workflow tracking data corresponding to the transaction object and the changed current workflow stage. 
     The steps may further comprise determining, by the watchdog microservice, that the stored workflow tracking data corresponding to the transaction object indicates that the transaction object completed each stage of the workflow corresponding to the transaction type and, in response to determining that the stored workflow tracking data indicates that the transaction object completed each stage of the workflow corresponding to the transaction type, removing the transaction object from the streaming data platform and outputting the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow. The current workflow stage of the transaction object may comprise a data structure indicating completion status of each respective step of a plurality of processing steps associated with the workflow. The steps may further comprise, in response to the determining that the current workflow stage of the transaction object has changed, determining, by the watchdog microservice, whether the current workflow stage of the transaction object is valid based on the workflow associated with the transaction type and, in response to determining that the current workflow stage of the transaction object is not valid, causing, by the watchdog microservice, the transaction object to be processed by one or more microservices associated with the workflow. The watchdog microservice may store workflow tracking data in an in-memory database. The workflow tracking data may comprise a timestamp and an indication of the change to the current workflow stage of the transaction object. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with the first microservice. The at least one performance metric may correspond to a single transaction object. The at least one performance metric may correspond to a group of transaction objects over a period of time. The steps may further comprise determining, by the watchdog microservice, that the at least one performance metric associated with the first microservice fails to satisfy at least one threshold performance value; and performing at least one action based on determining that the at least one performance metric fails to satisfy the at least one threshold performance value. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with the workflow. 
     The steps may further comprise determining, by the watchdog microservice, that the at least one performance metric associated with the workflow fails to satisfy at least one threshold performance value; and performing at least one action based on determining that the at least one performance metric fails to satisfy the at least one threshold performance value. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one baseline metric associated with the first microservice. The baseline metric may correspond to processing performance by the first microservice on a set of transaction objects over a period of time. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with a first transaction object processed by the first microservice; determining that the at least one performance metric associated with the first transaction object fails to satisfy a threshold relationship to the at least one baseline metric; and generating a recommended action to be taken on the first transaction object. The recommended action may comprise causing the first transaction object to be re-processed by the first microservice. The recommended action may comprise re-routing the first transaction object to be processed by another microservice. The recommended action may comprise changing the transaction type of the first transaction object. 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. Each microservice of the plurality of microservices may be configured to watch for transactions on the streaming data platform in a corresponding workflow stage based on a plurality of workflows corresponding to a plurality of transaction types. The memory may store instructions that, when executed by the at least one processor, cause the platform to perform steps including receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object, and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; and retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise processing, by the first microservice, the transaction object; updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed: retrieving, by the watchdog microservice and from the streaming data platform, the transaction object based on determining that the current workflow stage has changed; and storing, by the watchdog microservice, workflow tracking data corresponding to the transaction object and the changed current workflow stage; determining, by the watchdog microservice, that the stored workflow tracking data corresponding to the transaction object indicates that the transaction object completed each stage of the workflow corresponding to the transaction type; and in response to determining that the stored workflow tracking data indicates that the transaction object completed each stage of the workflow corresponding to the transaction type, removing the transaction object from the streaming data platform and output the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with the first microservice. The steps may further comprise determining, by the watchdog microservice, that the at least one performance metric associated with the first microservice fails to satisfy at least one threshold performance value; and generating a recommended action based on determining that the at least one performance metric fails to satisfy the at least one threshold performance value. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object, and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; and retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise processing, by the first microservice, the transaction object; updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed: retrieving, by the watchdog microservice and from the streaming data platform, the transaction object based on determining that the current workflow stage has changed; and storing, by the watchdog microservice, workflow tracking data corresponding to the transaction object and the changed current workflow stage; determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with the first microservice; and generating a graphic user interface display corresponding to the first microservice and comprising the at least one performance metric. 
     And according to some aspects, a computer-implemented method may comprise receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; and processing, by a first microservice, the transaction object on the streaming data platform based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; and in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed, storing workflow tracking data corresponding to the transaction object and the changed current workflow stage; determining, by the watchdog microservice, that the processing, by the first microservice, of the transaction object did not complete successfully; and causing the first microservice to repeat processing of the transaction object based on snapshot data corresponding to the transaction object captured by a snapshot microservice. 
     The steps may further comprise polling, by the snapshot microservice, the streaming data platform to retrieve transactions matching an initialization stage. Transactions may be added to the streaming data platform in the initialization stage. The initialization stage may be associated with the snapshot microservice. The steps may further comprise retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the transaction object; determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with addenda data of the transaction object has changed after the transaction object has left the initialization stage; and storing, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data. The snapshot microservice may cause the first microservice to repeat processing of the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice. Causing the first microservice to repeat processing of the transaction object may comprise regenerating, by the snapshot microservice, the transaction object based on snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice; and returning the regenerated transaction object to the streaming data platform. The current workflow stage of the regenerated transaction object may be set to the first workflow stage. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with the first microservice. Determining that the processing, by the first microservice, of the transaction object did not complete successfully may be based on determining that the at least one performance metric associated with the first microservice fails to satisfy at least one performance threshold value. The at least one performance metric may correspond to a single transaction object. The at least one performance metric may correspond to a group of transaction objects over a period of time. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one baseline metric associated with the first microservice. The baseline metric may correspond to processing performance by the first microservice on a set of transaction objects over a period of time. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with a first transaction object processed by the first microservice. Determining that the processing, by the first microservice, of the transaction object did not complete successfully may be based on determining that the at least one performance metric associated with the first transaction object fails to satisfy a threshold relationship to the at least one baseline metric. The steps may further comprise determining a number of times that the transaction object has undergone processing by the first microservice; in response to determining that the number of times that the transaction object has undergone processing by the first microservice exceeds a threshold value, rejecting the transaction object as having failed processing associated with the first microservice; and determining a corrective action for the transaction object based on rejecting the transaction object. The corrective action may comprise re-routing the first transaction object to be processed by another microservice. The corrective action may comprise changing the transaction type of the transaction object. The corrective action may comprise changing the indication of the workflow corresponding to the transaction type of the transaction object. 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. Each microservice of the plurality of microservices may be configured to watch for transactions on the streaming data platform in a corresponding workflow stage based on a plurality of workflows corresponding to a plurality of transaction types. The memory may store instructions that, when executed by the at least one processor, cause the platform to perform steps including receiving a transaction object comprising transaction details, addenda data, and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; and polling, by a snapshot microservice, the streaming data platform to retrieve transactions matching an initialization stage. Transactions may be added to the streaming data platform in the initialization stage. The initialization stage may be associated with the snapshot microservice. The steps may further comprise retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the transaction object; and processing, by a first microservice, the transaction object on the streaming data platform based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with the addenda data of the transaction object has changed after the transaction object has left the initialization stage; and storing, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data; updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; and, in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed, storing workflow tracking data corresponding to the transaction object and the changed current workflow stage; determining, by the watchdog microservice, that the processing, by the first microservice, of the transaction object did not complete successfully; and causing the first microservice to repeat processing of the transaction object based on the snapshot data corresponding to the transaction object captured by a snapshot microservice. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise receiving a transaction object comprising transaction details, addenda data, and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object, and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform. The transaction object may be added to the streaming data platform in an initialization stage. The steps may further comprise polling, by the snapshot microservice, the streaming data platform to retrieve transactions matching the initialization stage. The initialization stage may be associated with the snapshot microservice. The steps may further comprise retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the transaction object; and processing, by the first microservice, the transaction object on the streaming data platform based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with addenda data of the transaction object has changed after the transaction object has left the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data; updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; and in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed, storing workflow tracking data corresponding to the transaction object and the changed current workflow stage; determining, by the watchdog microservice, that the processing, by the first microservice, of the transaction object did not complete successfully; and causing the first microservice to repeat processing of the transaction object based on snapshot data corresponding to the transaction object captured by a snapshot microservice by: regenerating, by the snapshot microservice, the transaction object based on snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice; and returning the regenerated transaction object to the streaming data platform. The current workflow stage of the regenerated transaction object may be set to the first workflow stage. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one baseline metric associated with the first microservice. The baseline metric may correspond to processing performance by the first microservice on a set of transaction objects over a period of time. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with the first transaction object processed by the first microservice. Determining that the processing, by the first microservice, of the transaction object did not complete successfully may be based on determining that the at least one performance metric associated with the single transaction objects fails to satisfy a threshold relationship to the at least one baseline metric. 
     According to some aspects, a computer-implemented method may comprise steps comprising receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; and processing, by a first microservice, the transaction object on the streaming data platform based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; and, in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed, storing workflow tracking data corresponding to the transaction object and the changed current workflow stage; determining, by the watchdog microservice, that the processing, by the first microservice, of the transaction object did not complete successfully; and reconfiguring the first microservice or a related second microservice based on determining that the processing, by the first microservice, of the transaction object did not complete successfully. The steps may further comprise causing the first microservice to repeat processing of the transaction object based on snapshot data corresponding to the transaction object captured by a snapshot microservice; and determining that the repeat processing of the transaction object also did not complete successfully. Reconfiguring the first microservice or the related second microservice may be based on determining that the repeat processing of the transaction object failed. Reconfiguring the first microservice or a related second microservice may comprise generating a configuration transaction object that may be configured to cause reconfiguration of the first workflow by causing reconfiguration of the first microservice. The configuration transaction object may comprise transaction metadata that indicates a configuration workflow and a current workflow stage of the configuration transaction object. The steps may further comprise adding the configuration transaction object to the streaming data platform; updating the current workflow stage of the configuration transaction object to the first workflow stage; retrieving, by the first microservice and from the streaming data platform, the configuration transaction object based on the current workflow stage matching the first workflow stage; and processing, by the first microservice, the configuration transaction object to reconfigure the first microservice. Reconfiguring the first microservice or the related second microservice may cause transaction objects associated with the workflow to be dynamically re-routed. Reconfiguring the first microservice or the related second microservice may comprise reconfiguring the first microservice to modify at least one operation that the first microservice performs on transaction objects associated with the workflow. Reconfiguring the first microservice or the related second microservice may comprise reconfiguring the related second microservice to cause removal of the first microservice from the workflow. The second related microservice may be a predecessor microservice that proceeds the first microservice in the workflow. The steps may further comprise determining, by the watchdog microservice, at least one performance metric associated with the first micro service. Determining that the processing, by the first microservice, of the transaction object did not complete successfully may be based on determining that the at least one performance metric associated with the first microservice fails to satisfy at least one threshold performance value. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with the workflow. Determining that the processing, by the first microservice, of the transaction object did not complete successfully may be based on determining that the at least one performance metric associated with the workflow fails to satisfy at least one threshold performance value. 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. Each microservice of the plurality of microservices may be configured to watch for transactions on the streaming data platform in a corresponding workflow stage based on a plurality of workflows corresponding to a plurality of transaction types. The memory may store instructions that, when executed by the at least one processor, cause the platform to perform steps including receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; and processing, by the first microservice, the transaction object on the streaming data platform based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; and in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed, storing workflow tracking data corresponding to the transaction object and the changed current workflow stage; determining, by the watchdog microservice, that the processing, by the first microservice, of the transaction object did not complete successfully; and reconfigure the first microservice based on determining that the processing, by the first microservice, of the transaction object did not complete successfully by generating a configuration transaction object that may be configured to cause reconfiguration of the first microservice and adding the configuration transaction object to the streaming data platform. The steps may further comprise causing the first microservice to repeat processing of the transaction object based on snapshot data corresponding to the transaction object captured by a snapshot microservice; and determining that the repeat processing of the transaction object also did not complete successfully. Reconfiguring the first microservice may be based on determining that the repeat processing of the transaction object failed. Reconfiguring the first microservice may cause transaction objects associated with the workflow to be dynamically re-routed. Reconfiguring the first microservice may comprise reconfiguring the first microservice to modify at least one operation that the first microservice performs on transaction objects associated with the workflow. Reconfiguring the first microservice may comprise reconfiguring a related second microservice to cause the removal of the first microservice from the workflow. The second related microservice may be a predecessor microservice that proceeds the first microservice in the workflow. The steps may further comprise determining, by the watchdog microservice, at least one performance metric associated with the first micro service. Determining that the processing, by the first microservice, of the transaction object did not complete successfully may be based on determining that the at least one performance metric associated with the first microservice fails to satisfy at least one threshold performance value. The steps may further comprise determining, by the watchdog microservice and based on the workflow tracking data, at least one performance metric associated with the workflow. Determining that the processing, by the first microservice, of the transaction object did not complete successfully may be based on determining that the at least one performance metric associated with the workflow fails to satisfy at least one threshold performance value. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise receiving a transaction object comprising transaction details and transaction metadata. The transaction metadata may comprise an indication of a workflow corresponding to a transaction type of the transaction object and a current workflow stage of the transaction object. The workflow corresponding to the transaction type may comprise a plurality of processing steps required to approve a given transaction of the transaction type. The steps may further comprise adding the transaction object to a streaming data platform; and processing, by a first microservice, the transaction object on the streaming data platform based on the current workflow stage matching a first workflow stage. The first workflow stage may be associated with the first microservice based on the workflow corresponding to the transaction type. The steps may further comprise updating the current workflow stage of the transaction object to a second workflow stage based on completing processing, by the first microservice, of the transaction object; and, in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed, storing workflow tracking data corresponding to the transaction object and the changed current workflow stage; determining, by the watchdog microservice, that the processing, by the first microservice, of the transaction object did not complete successfully; causing the first microservice to repeat processing of the transaction object based on snapshot data corresponding to the transaction object captured by a snapshot microservice; and determining that the repeat processing of the transaction object also did not complete successfully; and reconfiguring the first microservice or a related second microservice, based on determining that the repeat processing of the transaction object also did not complete successfully. Reconfiguring the first microservice may comprise generating a configuration transaction object that may be configured to cause reconfiguration of the first workflow by causing reconfiguration of the first microservice. The configuration transaction object may comprise transaction metadata that indicates a configuration workflow, and a current workflow stage of the configuration transaction object. Reconfiguring the first microservice may further comprise adding the configuration transaction object to the streaming data platform; updating the current workflow stage of the configuration transaction object to the first workflow stage; retrieving, by the first microservice and from the streaming data platform, the configuration transaction object based on the current workflow stage matching the first workflow stage; and processing, by the first microservice, the configuration transaction object to reconfigure the first microservice. Reconfiguring the first microservice or the related second microservice may cause transaction objects associated with the workflow to be dynamically re-routed. 
     Consensus Key Locking 
     The transaction exchange platform described herein is designed to choreograph a series of events into payment flows (sagas). The transaction exchange platform choreographs the payment flows using a plurality of microservices that are designed to process streaming data and handle duplicate content. Additionally, the transaction exchange platform may also include built-in replay capabilities to ensure that saga flows progress through to completion. Because large sums of money are regularly processed by the transaction exchange platform, the transaction exchange platform needs to be a highly available system. To accomplish high availability, several instances of the transaction exchange platform may execute concurrently, in different geographical locations. Each instance of the transaction exchange platform may be referred to as a cluster, or a single cluster. 
     Some transactions handled by the transaction exchange platform are extremely sensitive to duplicate data. Because of this, the transaction exchange platform must guarantee idempotent transactions have the ability to lock a key, resource, and/or data, across all instances, in all regions. However, existing solutions suffer from shortcomings. For example, traditional write forward mechanisms, such as Redis Active-Active, have a window where cross-region writes eventually become consistent and could allow instances in both regions to believe that they own the lock, resulting in the potential for duplicate processing. Furthermore, existing database solutions are unable to guarantee idempotent transactions have the ability to lock a key, resource, and/or data, across all instances, in all regions. In this regard, relational databases, such as AWS Aurora (MySQL Multi-mater), have performance issues with frequent conflict resolution, which is to be expected when processing replicated streaming data in multiple regions. Other databases, like Cockroach DB, etcd, RedisRaft, and the like, may offer consensus protocol solutions, like Raft, which may provide a locking mechanism. However, these other databases may attempt to version each update, which would require consensus overhead that would increase latency. Additionally or alternatively, these other databases may allow subsequent changes to be made provided there was not a simultaneous write conflict. Another problem is that these other databases tend to hold a limited amount of data due to the synchronization of snapshots. Moreover, the databases that implement consensus protocols traditionally solve for a single instance lock acquisition and are, therefore, relatively slow and unable to scale. In conclusion, database solutions that use the consensus protocol for all read and write transactions would incur too much overhead and latency to be able to function effectively in a production environment. 
     The present disclosure overcomes the shortcomings of prior solutions by providing a locking microservice that enables lock acquisition consensus across a geographically distributed system, with fast read/write access to corresponding value data stored in the region processing the transaction. The locking microservice may leverage the consensus protocol only when acquiring a lock on a key value and handles all other aspects of data access with a local fast write forward system. This is an improvement over existing systems since leveraging consensus protocol only when acquiring a lock on a key value, and handling all other aspects of data access with a fast write forward system, guarantees idempotent transactions in a system with data replicated across regions. By limiting the consensus protocol interactions only to writing unique keys—which is done once per transaction, the locking microservice described herein improves performance by storing metadata and/or application-related state details in the local cache system after the lock is acquired. This improves the performance and reliability of the distributed locking mechanism described herein. Moreover, performance may be further improved by sharding data across different consensus clusters and managing leader and quorum placement in the region with the highest volume of traffic. 
       FIG.  16    illustrates a transaction processing system  1600  that may be similar to transaction processing systems  300 ,  600 , and/or  900  of  FIGS.  3 A,  6 , and  9   , respectively. Relative to systems  300 ,  600 , and/or  900 , transaction processing system  1600  may add locking microservice  1610 , a local storage system  1615 , and a distributed lock manager  1620 . Although not shown in  FIG.  16   , transaction exchange platform  320  may be one of several transaction exchange platforms associated with transaction processing system  1600 . In this regard, each one of the several transaction exchange platforms may be associated with a geographic region. 
     Locking microservice  1610  may operate on transaction exchange platform  320  to acquire one or more locks on key values, data, and/or resources on behalf of the plurality of microservices (e.g., first microservice  331 , second microservice  332 , third microservice  333 , . . . nth microservice  334 ) executing on transaction exchange platform  320 . Several instances of locking microservice  1610  may exist in transaction processing system  1600 , with each instance being associated with a transaction exchange platform located in a different geographic region. 
     According to one embodiment, locking microservice  1610  may receive a request for a lock for a first resource, for example, first microservice  331 . As noted above, the first resource may be an entry in a database. The entry may be determined based on one or more key values. In response to receiving the request, locking microservice  1610  may determine whether a lock exists for the first resource. Locking microservice  1610  may determine whether a lock exists for the first resource by querying a local data structure, such as local storage system  1615 . In this regard, local storage system  1615  may be cache system associated with the transaction exchange platform  320 . In some instances, local storage system  1615  is a fast write forward mechanism, like Redis. If locking microservice  1610  determines that a lock exists for the first resource, locking microservice  1610  may notify first microservice  331 . In some instances, locking microservice  1610  may attempt to acquire the lock for the first resource periodically. When locking microservice  1610  determines that a lock does not exist for the first resource, locking microservice  1610  may transmit an inquiry to distributed lock manager  1620  to determine whether a lock exists for the first resource. In this regard, another microservice executing on a different transaction exchange platform, located in a different geographic region, may own a lock on the first resource. Distributed lock manager  1620  may be associated with one or more databases. As will be discussed in greater detail below, distributed lock manager  1620  may invoke a consensus protocol to determine whether to grant a lock on the first resource. Locking mechanism  1610  may receive a response to the inquiry. Similar to the request made to local storage system  1615 , locking microservice  1610  may attempt to acquire the lock for the first resource periodically, for example, if the response indicates that a lock exists for the first resource. However, when a lock does not exist for the first resource, locking microservice  1610  may send (e.g., transmit) a request for a lock for the first resource to distributed lock manager  1620 . Distributed locking manager  1620  may then send (e.g., transmit) the lock for the first resource to locking microservice  1610 . Upon being granted the lock, locking microservice  1610  may notify first microservice  331  that a lock for the first resource has been acquired. Additionally, locking microservice  1610  may send (e.g., transmit) a notification to one or more locking microservices, each associated with a transaction exchange platform of a different geographic location, indicating that first microservice  331  has acquired a lock for the first resource. The notification may comprise a synchronization signal. Similarly, locking microservice  1610  may send (e.g., transmit) a synchronization signal indicating an updated value for the first resource, for example, after first microservice  331  has processed the transaction. Additionally, locking microservice  1610  may send (e.g., transmit) a request to release the lock, for example, based on a determination that first microservice  331  has completed processing of a transaction object using the first resource. 
       FIG.  17    depicts an illustrative method  1700  for obtaining a lock on a resource according to one or more aspects of the disclosure. Method  1700  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1700 . 
     As noted above, a transaction exchange platform may receive a first transaction object corresponding to a first payment transaction. As noted above, first transaction exchange platform may comprise one or more server clusters, with each of the one or more server clusters being associated with a geographic region. The transaction exchange platform may comprise a single streaming data platform (SDP) that is accessible by the one or more server clusters. Further, each of the one or more server clusters may comprise microservices, such as microservices for processing the transaction object according to a workflow. Additionally, each of the one or more server clusters may also include microservices for managing the processing of the transaction objects, such as the watchdog microservice, the snapshot microservice, the locking microservice, etc. There may be multiple instances of each microservice running in all regions. As shown in  FIG.  17   , the transaction exchange platform comprises a first geographic region  1701  and a second geographic region  1702 . The second geographic region may be different from the first geographic region. In response to receiving the transaction object, a microservice from either region (e.g., first geographic region  1701 , second geographic region  1702 ) may retrieve a plurality of transaction objects, including the first transaction object, from the SDP. As noted above, the microservice may compare a workflow of each of the plurality of transaction objects to the workflow associated with the microservice. If the workflow of the transaction object matches the workflow associated with the microservice, the microservice may process the transaction object. 
     Returning to  FIG.  17   , first microservice  331  may retrieve a plurality of transaction objects, including the first transaction object, from the SDP. First microservice  331  may compare a workflow of the first transaction object to the workflow associated with first microservice  331 . When the workflow of the first transaction object matches the workflow associated with first microservice  331 , first microservice  331  may process the first transaction object. While processing the first transaction object, first microservice may determine that the processing of the first transaction object requires use of a first resource, such as a database entry, a table entry, a key value associated with a database entry or a table entry, etc. In step  1705 , first microservice  331  may send a request for a lock on the first resource. Locking microservice  1610 , associated with the first geographic region  1701 , may receive the request for the lock for the first resource from first microservice  331 . In step  1715 , first locking microservice  1610  may determine whether a lock exists for the first resource. Determining whether a lock exists for the first resource may comprise querying a local data structure, such as first local storage  1615 . As noted above, first local storage  1615  may be similar to the local storage system  1615 , described in  FIG.  16   . In step  1725 , first locking microservice  1610  may receive a response to the query. As shown in  FIG.  17   , the response to first locking mechanism  331  indicates that a lock does not exist for the first resource. Based on a determination that a lock does not exist for the first resource, first locking microservice  331  may send (e.g., transmit) a request for a lock on the first resource to distributed lock manager  1610 , in step  1735 . In some examples, first locking microservice  331  may send an inquiry to distributed lock manager  1610  to determine whether a lock exists for the first resource. The request for the lock on the first resource may be sent in response to receiving a response from distributed lock manager  1610  that indicates that a lock does not exist for the first resource. 
     In response to receiving the request for the lock from first locking microservice  331 , distributed lock manager  1620  may invoke a consensus protocol to determine whether to grant the lock on the first resource to first microservice  331 . According to some examples, the quorum for the consensus protocol may be located in the same region where the most traffic is occurring. Requests from other regions may be routed to the region where the most traffic is occurring, for example, using DNS and/or latency-based rules. By routing requests from other regions to the region with quorum, the present disclosure can avoid having to resolve consensus across elector nodes in different geographic regions. In some instances, distributed lock manager  1620  may query each of the one or more server clusters to render a determination as to whether to grant the lock on the first resource to first microservice  331 . If distributed lock manager  1620  receives responses indicating that the lock should not be granted to first microservice  331 , distributed lock manager  1620  may deny the request for the lock on the first resource. Similarly, if distributed lock manager  1620  receives less than a threshold amount of responses indicating that the lock should be granted to first microservice  331  (e.g., ≤50%), distributed lock manager  1620  may deny the request for the lock on the first resource. However, when distributed lock manager  1620  receives more than a threshold amount of responses indicating that the lock should be granted to first microservice  331  (e.g., &gt;50%), distributed lock manager  1620  may grant the request for the lock. In step  1745 , distributed lock manager  1620  may send a response to first locking microservice  1610 . The response may indicate that the lock on the first resource has been granted. First locking service  1610  may receive the response. In step  1747 , first locking microservice  1610  may send (e.g., transmit), to first microservice  331 , an indication that a lock for the first resource has been acquired. In response to receiving the indication, first microservice  331  may process the first transaction object using the first resource. Processing the first transaction object may cause first microservice  331  to generate an updated value of the first resource. Additionally or alternatively, processing the first transaction object may include updating a region associated with the first transaction object and/or updating the workflow stage associated with the first transaction object. In  FIG.  17   , first microservice  331  may update the region associated with the first transaction object to indicate first geographic region  1701 . After obtaining the lock, first locking microservice  1610  may synchronize the lock with the local storage systems associated with each of the one or more server clusters. For example, first locking microservice  1610  may set the lock in first lock storage system  1615 , in step  1755 . Additionally or alternatively, setting the lock may comprise updating state details, such as a microservice processing the first transaction object, a geographic region processing the first transaction object, etc., associated with the processing of the first transaction object. Similarly, first locking microservice  1610  may send a synchronization signal to the other local storage systems, in step  1760 . The synchronization signal may indicate that first microservice  331  has acquired a lock on the first resource. Additionally or alternatively, the synchronization signal may comprise one or more state details associated with the processing of the first transaction object. 
     At, or around, the same time first microservice  331  sends the request for the lock on the first resource, second microservice  1731  may issue a similar request for the first resource, in step  1710 . As shown in  FIG.  17   , second microservice  1731  may be executing in second geographic region  1702 . It will be appreciated that second microservice  1731  may execute in the same geographic region (e.g., first geographic region  1701 ) as first microservice  331 . In this regard, two or more entities executing in separate threads of the same application or separate containers in the same region may contend for a lock on the same resource key. Second microservice  1731  may send the request for the lock on the first resource to second locking microservice  1703 . Second locking microservice  1703  may query second local storage  1707  to determine whether a lock exists on the first resource. Second local storage  1707  may be similar to first local storage  1615 . Because first microservice  331  had not yet acquired the lock on the first resource, second local storage  1707  may send a response indicating that a lock does not exist for the first resource, in step  1730 . In response to receiving the response from second local storage  1707 , second locking microservice  1703  may send (e.g., transmit) a request for a lock on the first resource to distributed lock manager  1610 , in step  1740 . As shown in  FIG.  17   , first locking microservice  1610  may beat the second locking microservice  1703  in the request for the first resource. Accordingly, distributed lock manager  1620  may deny the request from second region  1702 , in step  1750 . In this regard, distributed lock manager  1620  may send the denial to second locking microservice  1703 . Second locking microservice  1703  may receive the denial. In step  1753 , second locking microservice  1703  may send an indication to second microservice  1731  that the lock for the first resource was denied. 
     In some instances, the requests made in steps  1735  and  1740  may be received at, or about, the same time, thereby creating a race condition. As discussed above, distributed lock manager  1620  may invoke a consensus protocol amongst the one or more server clusters to resolve the race condition. Consensus may be performed, for example, when no prior data exists for a payment id, after a lock has timed out, and/or a process determined that a lock is stale and forced unlocked it such that there is contention for a new lock on the resource. Lock state details do not require consensus and may be written locally. In the examples described above, distributed lock manager  1620  may grant the lock to the region indicated by a majority of the one or more server clusters. 
     While first microservice  331  owns the lock on the first resource, other microservices may request access to the first resource. Additionally or alternatively, the other microservices may request a lock on the first resource. The request for the lock may be so that another microservice can process a transaction object using the first resource. Additionally or alternatively, the request for the lock may be to check on the status of the first resource. That is, another microservice, such as second microservice  1731 , may request a lock on the first resource to determine whether first microservice  331  has released the lock on the first resource. 
     Returning to  FIG.  17   , and specifically step  1765 , second microservice  1731  may request a lock for the first resource, for example, while first microservice  331  owns the lock on the first resource. Second microservice  1731  may issue (e.g., send, transmit) the request to second locking microservice  1703 . In response to receiving the request, second locking microservice  1703  may query second local storage  1707  to determine whether a lock exists for the first resource, for example, in step  1770 . Second local storage  1707  may receive the query and determine whether a lock exists for the first resource. In response to the synchronization signal sent by first locking microservice  1710 , second local storage  1707  may include a database entry indicating that a lock exists for the first resource. In step  1775 , second local storage may send a response to second locking microservice  1703 . As shown in  FIG.  17   , the response sent in step  1775  may indicate that the lock already exists. In step  1780 , second locking microservice  1703  may indicate that the lock exists and any request issued by second microservice  1731  for a lock on the first resource may be denied. 
     The locking procedures described in  FIG.  17    ensure the integrity of data being processed by the transaction exchange platform. Additionally, the locking procedures, and in particular, the combination of the fast local storage and the distributed lock manager provides an improvement over prior art systems, which would require the requesting platform to poll each of the one or more server clusters individually to obtain a lock on a resource. By providing a local fast cache storage to manage locks and a centralized lock manager, the locking mechanisms described herein improve the speed with which distributed processing occurs, while ensuring that competing processing platforms do not corrupt data. 
     First microservice  331  may own the lock on the first resource until first microservice  331  completes processing of the first transaction object using the first resource. When processing of the first transaction object using the first resource is complete, first microservice  331  may release the lock on the first resource.  FIG.  18    depicts an illustrative method  1800  for releasing a lock on a resource according to one or more aspects of the disclosure. Method  1800  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1800 . 
     After completing processing of first transaction object, first microservice  331  may update a value of the first resource. Updating the value may comprise writing one or more pieces of information to a database entry. In step  1810 , first microservice  331  may transmit the updated value to first local storage  1615 . The updated value may be an updated value to be stored in a database entry of the first resource. Additionally or alternatively, the updated value may include state details associated with the processing of the first transaction object. For example, the updated value may comprise a geographic region processing the first transaction object. Additionally or alternatively, the updated value may comprise intermediate processing results of the first transaction object. 
     In step  1815 , first local storage  1615  may send (e.g., transmit) a synchronization signal to second locking microservice  1715 . The synchronization signal may indicate the updated value for the first resource. First local storage  1615  may send the synchronization signal to the local storage associated with each of the one or more server clusters. In step  1820 , first microservice  331  may send (e.g., transmit) a request to release the lock on the first resource to first locking microservice  1610 . As noted above, the request to release the lock on the first resource may be based on a determination that first microservice  331  has completed processing of the first transaction object using the first resource. In step  1825 , first locking microservice  1610  may send (e.g. transmit) a request to release the lock on the first resource to distributed lock manager  1620 . In some examples, the request to release the lock may include one or more updated values for the first resource. In response to receiving the request to release the lock on the first resource, distributed lock manager  1620  may send a synchronization signal to each local storage of the one or more server clusters, in step  1830 . The synchronization signal may update the status of the lock on the first resource. Additionally or alternatively, the synchronization signal may update the value of the first resource and step  1815  may be skipped. After the lock on the first resource may be skipped, other microservices may obtain a lock on the first resource. 
     In step  1835 , second microservice  1731  may send a request for a lock on the first resource. Second locking microservice  1703  may receive the request for the lock for the first resource from second microservice  1731 . In step  1840 , second locking microservice  1703  may determine whether a lock exists for the first resource by querying second local storage  1707 . In step  1845 , second local storage  1715  may send (e.g. transmit) a response to second locking microservice  1703  indicating that a lock does not exist on the first resource. In step  1845 , second locking microservice  1703  may send (e.g., transmit) a request for a lock on the first resource to distributed lock manager  1620 . Distributed lock manager  1620  may receive the request for the lock on the first resource. Similar to the techniques described above, distributed lock manager  1620  may invoke a consensus protocol to determine whether to grant the lock to second microservice  1731 . Distributed lock manager  1620  may determine that the request for the lock should be granted to second microservice  1731 . In step  1850 , distributed lock manager  1620  may send (e.g., transmit) an indication to second locking microservice  1703  that the request for the lock on the first resource has been granted to second microservice  1731 . After receiving the lock, second locking microservice  1703  may synchronize the lock with the local storage systems associated with each of the one or more server clusters. In step  1855 , second locking microservice  1703  may initially set the lock in second lock storage system  1715 . In step  1860 , second locking microservice  1610  may then send a synchronization signal to the other local storage systems. The synchronization signal may indicate that second microservice  1731  has acquired a lock on the first resource. 
     The techniques described above with respect to  FIGS.  17  and  18    may be used to obtain and release locks on shared and/or commonly accessed resources, such as database entries, applications, etc. The use of the fast local storage and the consensus protocol by the distributed lock manager resolves race conditions for resources quickly and ensures the integrity of the data. 
     According to other embodiments, a computer-implemented method may receive, by a transaction exchange platform, a transaction object corresponding to a first payment transaction. The transaction exchange platform may comprise a first streaming data platform associated with a first geographic region and a second stream data platform associated with a second geographic region. The computer-implemented method may determine, by the first microservice during processing of the transaction object, that the processing of the transaction object requires use of a first resource, for example, in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice. The first resource may be an entry in a database. The computer-implemented method may receive, by a locking microservice from the first microservice, a request for a lock for the first resource. The computer-implemented method may determine, by the locking microservice and based on querying a local data structure, whether a lock exists for the first resource. The computer-implemented method may transmit, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource, for example, based on a determination that a lock does not exist for the first resource. The computer-implemented method may receive a response to the inquiry that indicates that a lock does not exist for the first resource. The computer-implemented method may transmit, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource. The computer-implemented method may receive, by the locking microservice from the distributed lock manager, a lock for the first resource. The lock may be granted based on a consensus protocol indicating that the lock should be granted to the first microservice. The computer-implemented method may transmit, by the locking microservice to the first microservice, an indication that a lock for the first resource has been acquired. The computer-implemented method may process, by the first microservice, a first transaction object using the first resource to generate an updated value of the first resource, for example, in response to receiving the indication. Processing the first transaction object may comprise updating a region associated with the first transaction object and the workflow stage associated with the first transaction object. The computer-implemented method may transmit, by the locking microservice to a second locking microservice associated with the second streaming data platform, a synchronization signal indicating that the first microservice has acquired a lock for the first resource. The computer-implemented method may transmit, by the locking microservice to a second locking microservice associated with the second streaming data platform, a synchronization signal indicating the updated value for the first resource. The computer-implemented method may transmit, by the first microservice to the locking microservice, a request to release the lock based on a determination that the first microservice has completed processing of the first transaction object using the first resource. 
     The computer-implemented method may receive, by a second locking microservice from a second microservice and during processing of the transaction object by the first microservice, a request for a lock on the first resource. The second locking microservice may be associated with the second streaming data platform and/or a second geographic region. The computer-implemented method may determine, by the second locking microservice and based on querying a second local data structure, that a lock exists for the first resource. 
     The computer-implemented method may receive, by a second locking microservice from a second microservice and during processing of the transaction object by the first microservice, a request for a lock on the first resource. The second locking microservice may be associated with the second streaming data platform and/or a second geographic region. The computer-implemented method may determine, by the second locking microservice and based on querying a second local data structure, whether a lock exists for the first resource. The computer-implemented method may transmit, by the second locking microservice to the distributed lock manager, an inquiry whether a lock exists for the first resource, for example, based on a determination that a lock does not exist for the first resource. The computer-implemented method may receive a response to the inquiry that indicates that a lock exists for the first resource. 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. The plurality of microservices may comprise at least a first microservice, a first locking microservice, and/or a second locking microservice. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive, by a transaction exchange platform, a transaction object corresponding to a first payment transaction. The transaction exchange platform may comprise a first streaming data platform associated with a first geographic region and a second stream data platform associated with a second geographic region. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to determine, by the first microservice during processing of the transaction object, that the processing of the transaction object requires use of a first resource, for example, in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice. The first resource may be an entry in a database. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive, by a locking microservice from the first microservice, a request for a lock for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to determine, by the locking microservice and based on querying a local data structure, whether a lock exists for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource, for example, based on a determination that a lock does not exist for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive a response to the inquiry that indicates that a lock does not exist for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive, by the locking microservice from the distributed lock manager, a lock for the first resource. The lock may be granted based on a consensus protocol indicating that the lock should be granted to the first microservice. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the locking microservice to the first microservice, an indication that a lock for the first resource has been acquired. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to process, by the first microservice, a first transaction object using the first resource to generate an updated value of the first resource, for example, in response to receiving the indication. Processing the first transaction object may comprise updating a region associated with the first transaction object and the workflow stage associated with the first transaction object. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the locking microservice to a second locking microservice associated with the second streaming data platform, a synchronization signal indicating that the first microservice has acquired a lock for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the locking microservice to a second locking microservice associated with the second streaming data platform, a synchronization signal indicating the updated value for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the first microservice to the locking microservice, a request to release the lock based on a determination that the first microservice has completed processing of the first transaction object using the first resource. 
     The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive, by a second locking microservice from a second microservice and during processing of the transaction object by the first microservice, a request for a lock on the first resource. The second locking microservice may be associated with the second streaming data platform and/or a second geographic region. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to determine, by the second locking microservice and based on querying a second local data structure, that a lock exists for the first resource. 
     The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive, by a second locking microservice from a second microservice and during processing of the transaction object by the first microservice, a request for a lock on the first resource. The second locking microservice may be associated with the second streaming data platform and/or a second geographic region. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to determine, by the second locking microservice and based on querying a second local data structure, whether a lock exists for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the second locking microservice to the distributed lock manager, an inquiry whether a lock exists for the first resource, for example, based on a determination that a lock does not exist for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive a response to the inquiry that indicates that a lock exists for the first resource. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise receiving, by a transaction exchange platform, a transaction object corresponding to a first payment transaction, wherein the transaction exchange platform comprises a first streaming data platform associated with a first geographic region and a second stream data platform associated with a second geographic region; in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice, determining, by the first microservice during processing of the transaction object, that the processing of the transaction object requires use of a first resource; receiving, by a locking microservice from the first microservice, a request for a lock for the first resource; determining, by the locking microservice and based on querying a local data structure, whether a lock exists for the first resource; based on a determination that a lock does not exist for the first resource, transmitting, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource; receiving a response to the inquiry, wherein the response comprises an indication that a lock does not exist for the first resource; transmitting, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource; receiving, by the locking microservice from the distributed lock manager, a lock for the first resource, wherein the lock is granted based on a consensus protocol indicating that the lock should be granted to the first microservice; transmitting, by the locking microservice to the first microservice, an indication that a lock for the first resource has been acquired; and in response to receiving the indication, processing, by the first microservice, a first transaction object using the first resource to generate an updated value of the first resource. Those steps may also include transmitting, by the locking microservice to a second locking microservice associated with the second streaming data platform, a synchronization signal indicating that the first microservice has acquired a lock for the first resource. The steps further include transmitting, by the locking microservice to a second locking microservice associated with the second streaming data platform, a synchronization signal indicating the updated value for the first resource. The steps also include transmitting, by the first microservice to the locking microservice, a request to release the lock based on a determination that the first microservice has completed processing of the first transaction object using the first resource. The steps may comprise receiving, by a second locking microservice from a second microservice and during processing of the transaction object by the first microservice, a request for a lock on the first resource, wherein the second locking microservice is associated with the second streaming data platform; and determining, by the second locking microservice and based on querying a second local data structure, that a lock exists for the first resource. The steps may further comprise receiving, by a second locking microservice from a second microservice and during processing of the transaction object by the first microservice, a request for a lock on the first resource, wherein the second locking microservice is associated with the second streaming data platform; determining, by the second locking microservice and based on querying a second local data structure, whether a lock exists for the first resource; based on a determination that a lock does not exist for the first resource, transmitting, by the second locking microservice to the distributed lock manager, an inquiry whether a lock exists for the first resource; and receiving a response to the inquiry, wherein the response comprises an indication that a lock exists for the first resource. 
     Occasionally, processing of a first transaction object may fail while a lock is in place.  FIGS.  19 A and  19 B  depict an illustrative method  1900  for resolving a lock when processing of a transaction that owns the lock fails according to one or more aspects of the disclosure. Method  1900  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  1900 . 
     As noted above, first microservice  331  may retrieve a plurality of transaction objects, including the first transaction object, from an SDP. After comparing a workflow of the first transaction object to the workflow associated with first microservice  331 , first microservice  331  may process the first transaction object and, while processing the first transaction object, determine that the processing of the first transaction object requires use of a first resource. 
     In step  1905 , first microservice  331  may send a request for a lock on the first resource. Locking microservice  1610  may receive the request for the lock for the first resource from first microservice  331 . In step  1910 , first locking microservice  1610  may determine whether a lock exists for the first resource, for example, by querying a local data structure, such as first local storage  1615 . In step  1915 , first locking microservice  1610  may receive a response to the query indicating that a lock does not exist for the first resource. First locking microservice  331  may then send (e.g., transmit) a request for a lock on the first resource to distributed lock manager  1610 , in step  1920 . In response to receiving the request for the lock from first locking microservice  331 , distributed lock manager  1620  may invoke a consensus protocol to determine whether to grant the lock on the first resource to first microservice  331 . When distributed lock manager  1620  receives more than a threshold amount of responses indicating that the lock should be granted to first microservice  331  (e.g., &gt;50%), distributed lock manager  1620  may grant the request for the lock and send a response to first locking microservice  1610 , in step  1925 . First locking service  1610  may receive the response. In step  1930 , first locking microservice  1610  may notify first microservice  331  that a lock for the first resource has been acquired. Additionally, first locking microservice  1610  may synchronize the lock with the local storage systems associated with each of the one or more server clusters. For example, first locking microservice  1610  may set the lock in first local storage system  1615 , in step  1935 . In step  1940 , first local storage system  1615  may send a synchronization signal to update the lock status of the other local storage systems (e.g., second local storage system  1707 ). 
     In step  1945 , an error may occur while first microservice  331  processes the first transaction object while owning the lock on the first resource. For example, first microservice  331  may fail and/or crash, cause processing of the first transaction object to stall. In another example, the error may be based on a predetermined amount of time elapsing since the first lock was acquired without any updates to the workflow status of the first transaction object. As described above, watchdog microservice  980  may generate workflow tracking records for each transaction object on the transaction exchange platform  320 , and may store information indicating whether the transaction object completed each step of the workflow along with timestamps and other suitable metadata. Based on these tracking records, watchdog microservice  980  may determine that processing of the first transaction object has failed. In response to determining that processing of the first transaction object has failed, watchdog microservice  980  may attempt to re-generate the first transaction object locally (e.g., in the first geographic region  1701 ), for example, using the process shown in  FIG.  14    and described above. If the attempt to re-generate the first transaction object locally fails or processing of the first transaction object fails again, method  1900  may proceed to step  1950 . 
     In step  1950 , watchdog microservice  980  may cause the lock on the first lock to be released, for example, in response to determining that processing of the first transaction object has failed. Watchdog microservice  980  may send a signal to distributed lock manager  1620 , which may send signal to each local storage with an indication that the lock on the first resource should be released. Additionally or alternatively, watchdog microservice  980  may send a signal to each local storage system indicating that the lock on the first resource should be released. 
     In step  1955 , watchdog service  980  may transfer processing of the first transaction object from first microservice  331 , in the first region  1701 , to second microservice  1731 , in the second region  1702 . In addition to transfer processing of the first transaction object, watchdog microservice  980  may also transfer state details associated with processing of the first transaction object. For example, if first microservice  331  performed any processing of the first transaction object using the first resource, the state details and processed transaction details may be transferred to second microservice  1731 . These state details may include updating a workflow stage associated with the first transaction object to indicate that processing of the first transaction object is being handled by second region  1702 . After processing of the first transaction object has been transferred to the second region  1702 , second microservice  1731  may acquire a lock on the first resource in order to complete processing of the first transaction object. 
     In step  1960 , second microservice  1731  may send a request for a lock on the first resource. Second locking microservice  1703  may receive the request for the lock for the first resource from second microservice  1731 . In step  1965 , second locking microservice  1703  may determine whether a lock exists for the first resource by querying second local storage  1707 . In step  1970 , second local storage  1715  may send a response to second locking microservice  1703  indicating that a lock does not exist on the first resource. In step  1975 , second locking microservice  1703  may send (e.g., transmit) a request for a lock on the first resource to distributed lock manager  1620 . Distributed lock manager  1620  may receive the request for the lock on the first resource. In step  1980 , distributed lock manager  1620  may send (e.g., transmit) an indication to second locking microservice  1703  that the request for the lock on the first resource has been granted to second microservice  1731 , for example, based on a determination that the lock should be granted to second microservice  1731 . In step  1985 , second locking microservice  1703  may set the lock in the second local storage  1707 . In step  1990 , second locking microservice  1610  may then send a synchronization signal to the other local storage systems that indicates that second microservice  1731  has acquired a lock on the first resource. Second microservice  1731  may then process the first transaction object using the first resource to generate an updated value of the first resource. 
     According to other embodiments, a computer-implemented method may receive, by a transaction exchange platform, a transaction object corresponding to a first payment transaction. The transaction exchange platform may comprise a first geographic region and a second geographic region different from the first geographic region. The computer-implemented method may determine, by the first microservice while processing the transaction object, that the processing of the transaction object requires use of a first resource, for example, in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice. The first microservice may be associated with the first geographic region. The computer-implemented method may acquire, by a first locking microservice associated with the first geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a first lock for the first resource. The computer-implemented method may acquire the first lock for the first resource by receiving, by the first locking microservice from the first microservice, a request for a lock for the first resource; transmitting, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource based on a determination that a lock does not exist for the first resource in the local data structure; receiving, from the distributed lock manager, a response indicating a lock does not exist for the first resource; transmitting, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource; and receiving, by the locking microservice from the distributed lock manager, the first lock for the first resource, wherein the lock is granted based on a consensus protocol indicating that the first lock should be granted to the first microservice. 
     The computer-implemented method may process, by the first microservice, the transaction object using the first resource, for example, in response to receiving the first lock. Processing of the transaction object may comprise updating a workflow stage associated with the transaction object. The updated workflow stage may be transmitted to the second geographic region when the transaction object is transferred. The computer-implemented method may determine, by a watchdog microservice, that processing of the transaction object has failed. The determination that processing of the transaction object using the first resource has failed may be based on a predetermined amount of time elapsing since the first lock was acquired. The computer-implemented method may release, by the watchdog microservice and based on a determination that processing of the transaction object using the first resource has failed, the first lock from the first resource. The computer-implemented method may transfer, by the watchdog microservice, processing of the first transaction object to the second geographic region. The computer-implemented method may update a region associated with the first transaction object to the second geographic region, for example, in response to transferring the transaction object. The computer-implemented method may acquire, by a second locking microservice associated with the second geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a second lock for the first resource. The computer-implemented method may process, by a second microservice, the transaction object using the first resource to generate an updated value of the first resource, for example, in response to receiving the second lock. The computer-implemented method may transmit, by the second locking microservice, a request to release the lock, for example, based on a determination that the second microservice has completed processing of the transaction object using the first resource. 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. The plurality of microservices may comprise at least a first microservice, a second microservice, a first locking microservice, a second locking microservice, and/or a watchdog microservice. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive, by a transaction exchange platform, a transaction object corresponding to a first payment transaction. The transaction exchange platform may comprise a first geographic region and a second geographic region different from the first geographic region. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to determine, by the first microservice while processing the transaction object, that the processing of the transaction object requires use of a first resource, for example, in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice. The first microservice may be associated with the first geographic region. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to acquire, by a first locking microservice associated with the first geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a first lock for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to acquire the first lock for the first resource by receiving, by the first locking microservice from the first microservice, a request for a lock for the first resource; transmitting, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource based on a determination that a lock does not exist for the first resource in the local data structure; receiving, from the distributed lock manager, a response indicating a lock does not exist for the first resource; transmitting, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource; and receiving, by the locking microservice from the distributed lock manager, the first lock for the first resource, wherein the lock is granted based on a consensus protocol indicating that the first lock should be granted to the first microservice. 
     The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to process, by the first microservice, the transaction object using the first resource, for example, in response to receiving the first lock. Processing of the transaction object may comprise updating a workflow stage associated with the transaction object. The updated workflow stage may be transmitted to the second geographic region when the transaction object is transferred. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to determine, by a watchdog microservice, that processing of the transaction object has failed. The determination that processing of the transaction object using the first resource has failed may be based on a predetermined amount of time elapsing since the first lock was acquired. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to release, by the watchdog microservice and based on a determination that processing of the transaction object using the first resource has failed, the first lock from the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transfer, by the watchdog microservice, processing of the first transaction object to the second geographic region. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to update a region associated with the first transaction object to the second geographic region, for example, in response to transferring the transaction object. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to acquire, by a second locking microservice associated with the second geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a second lock for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to process, by a second microservice, the transaction object using the first resource to generate an updated value of the first resource, for example, in response to receiving the second lock. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the second locking microservice, a request to release the lock, for example, based on a determination that the second microservice has completed processing of the transaction object using the first resource. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise receiving, by a transaction exchange platform, a transaction object corresponding to a first payment transaction, wherein the transaction exchange platform comprises a first streaming data platform associated with a first geographic region and a second stream data platform associated with a second geographic region different from the first geographic region; in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice, determining, by the first microservice while processing the transaction object, that the processing of the transaction object requires use of a first resource, wherein the first microservice is associated with the first geographic region; acquiring, by a first locking microservice associated with the first geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a first lock for the first resource; determining, by a watchdog microservice, that processing of the transaction object has failed; releasing, by the watchdog microservice and based on a determination that processing of the transaction object using the first resource has failed, the first lock from the first resource; transferring, by the watchdog microservice, processing of the first transaction object to the second geographic region; acquiring, by a second locking microservice associated with the second geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a second lock for the first resource; and, in response to receiving the second lock, processing, by a second microservice, the transaction object using the first resource to generate an updated value of the first resource. The determination that processing of the transaction object using the first resource has failed may be based on a predetermined amount of time elapsing since the first lock was acquired. 
     The steps may include in response to receiving the first lock, processing, by the first microservice, the transaction object using the first resource, wherein processing the transaction object comprises updating a workflow stage associated with the transaction object, wherein the updated workflow stage is transmitted to the second geographic region when the transaction object is transferred. The steps may also include updating a region associated with the first transaction object to the second geographic region in response to transferring the transaction object. The steps may further comprise receiving, by the first locking microservice from the first microservice, a request for a lock for the first resource; based on a determination that a lock does not exist for the first resource in the local data structure, transmitting, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource; receiving, from the distributed lock manager, a response indicating a lock does not exist for the first resource; transmitting, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource; and receiving, by the locking microservice from the distributed lock manager, the first lock for the first resource, wherein the lock is granted based on a consensus protocol indicating that the first lock should be granted to the first microservice. The steps may also comprise transmitting, by the second locking microservice, a request to release the lock based on a determination that the second microservice has completed processing of the transaction object using the first resource. 
     According to some aspects, and as discussed above, the watchdog microservice may recommend as a corrective action replay of an earlier workflow stage for a transaction or group of transactions, for example in response to determining that processing of the transaction or group of transaction has failed and/or stalled. Working with the snapshot microservice, the watchdog microservice can cause a transaction object to revert to an earlier state, where the reversion to the current workflow stage of the transaction object would cause it to be processed again by an appropriate microservice. This is described further below with respect to  FIG.  20   . 
       FIG.  20    depicts a flowchart illustrating an example method  2000  for determining to replay a transaction on a transaction exchange platform, such as transaction exchange platform  320 . Method  2000  may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method  2000 .  FIG.  20    may combine aspects of  FIGS.  10  and  11   , as explained further below. 
     At step  2005 , the transaction exchange platform may receive a transaction object and add it to a SDP. The transaction object may be added to the SDP in an initialization stage. At step  2021 , watchdog microservice  2020  may track transaction objects as they progress through microservices and workflows, as described with respect to  FIG.  12    above. 
     At step  2023 , watchdog microservice  2020  may determine that a transaction object should replay a workflow stage. For example, the watchdog microservice  2020  may determine that a transaction object did not correctly complete the workflow step and/or that the microservice associated with the step is experiencing abnormal performance issues. In another example, watchdog microservice  2020  may determine that processing of a transaction object cannot progress within the timeframe defined by saga flow service level agreements in a single region and, therefore, issue the command that those transaction objects be replayed in other regions. At step  2025 , the watchdog microservice  2020  may command snapshot microservice  2030  to replay the transaction object at the earlier workflow stage. 
     Snapshot microservice  2030  may store snapshot data records for transaction objects on the SDP in steps  2031  and  2033 , as discussed above in  FIGS.  10  and  11   . At step  2035 , snapshot microservice  2030  may receive the command to replay the workflow step for the transaction object from the watchdog microservice  2020 . Snapshot microservice may rollback the transaction object and reinject it to the SDP at steps  2037  and  2039 , in the manner described above with respect to  FIG.  11   . In some instances, the microservice that previously processed the transaction object may acquire the transaction object from the SDP and re-attempt processing of the transaction object. In these instances, watchdog microservice  2020  may not cause the microservice&#39;s lock on the resource to be released. Alternatively, watchdog microservice  2020  may cause the lock to be released. Accordingly, the microservice may have to re-acquire a lock on the resource using the processes described above, for example, when the microservice begins processing the transaction object again. In yet another alternative, watchdog microservice  2020  may transfer processing of the transaction object to a different region, in step  2041 , as described above in  FIGS.  19 A and  19 B . In step  2043 , watchdog microservice  2020  may determine if the replayed workflow stage was processed successfully. If it processed successful, processing may proceed to step  2045  where the transaction workflow continues. 
     If, at step  2043 , watchdog microservice  2020  determines that processing did not complete successfully, watchdog microservice  2020  may determine a failure of the transaction to progress through the workflow stage at step  2047 . At step  2049 , the watchdog microservice  2020  may determine a further recommended action, such as triggering a dynamic reconfiguration of the workflow. 
     According to other embodiments, a computer-implemented method may receive a transaction object corresponding to a first payment transaction, wherein the transaction exchange platform comprises a first geographic region and a second geographic region different from the first geographic region. The computer-implemented method may determine, by the first microservice while processing the transaction object, that the processing of the transaction object requires use of a first resource, for example, in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice. The first microservice may be associated with the first geographic region. The computer-implemented method may acquire, by a first locking microservice associated with the first geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a lock for the first resource. The computer-implemented method may acquire the lock by receiving, by the first locking microservice from the first microservice, a request for a lock for the first resource; transmitting, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource based on a determination that a lock does not exist for the first resource in a local data structure; receiving, from the distributed lock manager, a response indicating a lock does not exist for the first resource; transmitting, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource; and receiving, by the locking microservice from the distributed lock manager, the lock for the first resource. The lock may be granted, for example, based on a consensus protocol indicating that the lock should be granted to the first microservice. 
     The computer-implemented method may determine, by a watchdog microservice, that processing of the transaction object has failed. The computer-implemented method may cause a first microservice to repeat processing of the transaction object based on snapshot data corresponding to the transaction object from prior to a start of the processing by the first microservice. The computer-implemented method may cause the first microservice to repeat processing of the transaction object by re-generating, by a snapshot microservice, the transaction object based on the snapshot data corresponding to the first transaction object from a point prior to a failure of the processing of the first transaction object; returning the regenerated first transaction object to a streaming data platform, wherein the workflow stage of the regenerated first transaction object is set to the first workflow stage; and re-acquiring, by the locking microservice, a lock for the first resource. The computer-implemented method may process, by the first microservice, the regenerated transaction object using the first resource to generate an updated value of the first resource. The computer-implemented method may transmit, by the locking microservice to a second locking microservice associated with a second streaming data platform associated with a geographic region that is different from a geographic region of the streaming data platform, a synchronization signal indicating the updated value for the first resource. 
     According to some aspects, a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory. The plurality of microservices may comprise at least a first microservice, a second microservice, a first locking microservice, a second locking microservice, a watchdog microservice, and/or a snapshot microservice. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to receive a transaction object corresponding to a first payment transaction, wherein the transaction exchange platform comprises a first geographic region and a second geographic region different from the first geographic region. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to determine, by the first microservice while processing the transaction object, that the processing of the transaction object requires use of a first resource, for example, in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice. The first microservice may be associated with the first geographic region. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to acquire, by a first locking microservice associated with the first geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a lock for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to acquire the lock by receiving, by the first locking microservice from the first microservice, a request for a lock for the first resource; transmitting, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource based on a determination that a lock does not exist for the first resource in a local data structure; receiving, from the distributed lock manager, a response indicating a lock does not exist for the first resource; transmitting, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource; and receiving, by the locking microservice from the distributed lock manager, the lock for the first resource. The lock may be granted, for example, based on a consensus protocol indicating that the lock should be granted to the first microservice. 
     The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to determine, by a watchdog microservice, that processing of the transaction object has failed. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to cause a first microservice to repeat processing of the transaction object based on snapshot data corresponding to the transaction object from prior to a start of the processing by the first microservice. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to cause the first microservice to repeat processing of the transaction object by re-generating, by a snapshot microservice, the transaction object based on the snapshot data corresponding to the first transaction object from a point prior to a failure of the processing of the first transaction object; returning the regenerated first transaction object to a streaming data platform, wherein the workflow stage of the regenerated first transaction object is set to the first workflow stage; and re-acquiring, by the locking microservice, a lock for the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to process, by the first microservice, the regenerated transaction object using the first resource to generate an updated value of the first resource. The memory may store instructions that, when executed by the at least one processor, cause the transaction exchange platform to transmit, by the locking microservice to a second locking microservice associated with a second streaming data platform associated with a geographic region that is different from a geographic region of the streaming data platform, a synchronization signal indicating the updated value for the first resource. 
     According to some aspects, one or more non-transitory computer readable media may comprise instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps. Those steps may comprise receiving, by a transaction exchange platform, a transaction object corresponding to a first payment transaction, wherein the transaction exchange platform comprises a first geographic region and a second geographic region different from the first geographic region; in response to retrieving a plurality of transaction objects from the first streaming data platform and based on a determination that a workflow stage of the transaction object matches a first workflow stage associated with a first microservice, determining, by the first microservice while processing the transaction object, that the processing of the transaction object requires use of a first resource, wherein the first microservice is associated with the first geographic region; acquiring, by a first locking microservice associated with the first geographic region and based on a determination that the processing of the transaction object requires use of the first resource, a lock for the first resource; determining, by a watchdog microservice, that processing of the transaction object has failed; causing a first microservice to repeat processing of the transaction object based on snapshot data corresponding to the transaction object from prior to a start of the processing by the first microservice, wherein causing the first microservice to repeat processing of the transaction object comprises: re-generating, by a snapshot microservice, the transaction object based on the snapshot data corresponding to the first transaction object from a point prior to a failure of the processing of the first transaction object; returning the regenerated first transaction object to a streaming data platform, wherein the workflow stage of the regenerated first transaction object is set to the first workflow stage; re-acquiring, by the locking microservice, a lock for the first resource; and processing, by the first microservice, the regenerated transaction object using the first resource to generate an updated value of the first resource. 
     Acquiring the lock for the first resource may include receiving, by the first locking microservice from the first microservice, a request for a lock for the first resource; based on a determination that a lock does not exist for the first resource in a local data structure, transmitting, by the locking microservice to a distributed lock manager, an inquiry whether a lock exists for the first resource; receiving, from the distributed lock manager, a response indicating a lock does not exist for the first resource; transmitting, by the locking microservice to the distributed lock manager and based on the response indicating that a lock does not exist for the first resource, the request for a lock for the first resource; and receiving, by the locking microservice from the distributed lock manager, the lock for the first resource, wherein the lock is granted based on a consensus protocol indicating that the lock should be granted to the first microservice. The steps may further comprise transmitting, by the first locking microservice, a request to release the lock based on a determination that the first microservice has completed processing of the transaction object using the first resource. The steps may also include transmitting, by the locking microservice to a second locking microservice associated with a second streaming data platform associated with a geographic region that is different from a geographic region of the streaming data platform, a synchronization signal indicating the updated value for the first resource. A determination to repeat processing of the transaction object may be based on a number of attempts at repeating processing of the first transaction being less than a threshold. The lock may not be released in response to a determination that processing of the transaction object by the first microservice has failed. 
     As noted above, the present disclosure provides a locking microservice that enables lock acquisition consensus across a geographically distributed system, with fast read/write access to corresponding value data stored in the region processing the transaction. The locking microservice may leverage the consensus protocol only when acquiring a lock on a key value and handles all other aspects of data access with a local fast write forward system. This is an improvement over existing systems since leveraging consensus protocol only when acquiring a lock on a key value, and handling all other aspects of data access with a fast write forward system, guarantees idempotent transactions in a system with data replicated across regions. By limiting the consensus protocol interactions only to writing unique keys—which is done once per transaction, the locking microservice described herein improves performance by storing metadata and/or application-related state details in the local cache system after the lock is acquired. This improves the performance and reliability of the distributed locking mechanism described herein. Moreover, performance may be further improved by sharding data across different consensus clusters and managing leader and quorum placement in the region with the highest volume of traffic. 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.