Orchestrate Architecture

Overview

Orchestrate implements a microservices architecture composed of APIs & Workers.

Description of the responsibilities for each component can be found on the section Tutorials/Run a sandbox of this documentation. Workers communicate using a publish-subscribe pattern, using Apache Kafka as message broker. In general, Orchestrate has a scalable and robust architecture design. The abstraction of components and the method of communication between microservices through a central message broker and defining a protocol for message exchanges, makes the application highly maintainable, loosely coupled with other services and easy to test.

Orchestrate‘s High level architecture

Orchestrate Workers

Orchestrate workers communicate following publish-subscribe pattern using Apache Kafka as message broker. All messages are standardized using protobuf and grpc.

• Tx-crafter consumes messages from tx crafting Kafka topic and publishes to tx nonce topic. It is responsible for crafting transactions payload, setting Gas Price of the transaction; setting Gas Limit of the transaction and requesting Faucet crediting.

• Tx-nonce is a worker responsible for setting transaction’s nonce. It consumes messages from the Apache Kafka tx nonce topic, and uses Redis as a distributed cache for nonce values.

• Tx-signer is a worker responsible for signing transactions. It consumes messages from tx signer Kafka topic and publishes to tx sender topic.

• Tx-sender is a worker responsible for sending transactions to the blockchain. At the moment of sending, it stores the transaction envelope thanks to the envelope-store.

• Tx-listener is a worker responsible for catching transaction receipts, loading & reconstituting Transaction Envelope by interrogating API-Context-Store. It consumes messages from tx signer Kafka topic. tx-listener is a completely asynchronous microservice, therefore it would listen to all transactions happening on the plugged blockchain.

• Tx-decoder is a worker responsible for decoding raw events logs from transactions into a human readable mapping of strings. It consumes messages from tx decoder Kafka topic and publishes to tx decoded topic.

• Tx-recover is a worker responsible for recovering errors during the transaction process.

• Tx-bridge is a worker responsible for performing bridge actions and catching a “RelayMessage” from a chain and broadcasting the message to an “AcceptMessage” to another chain. It consumes message from tx decoded Kafka topic and publish to tx crafter topic.

Orchestrate APIs

• Envelope Store is responsible for storing Transaction execution context while it’s being mined.
• Contract-Registry is responsible for storing Contract ABIs, bytecode, deployedBytecode.