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 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.

Info

Learn more about the Contract-Registry here.