Architecture

​

Architecture

Before starting with the Anchor Platform, let’s get familiar with the architecture. This section will describe the components involved and how they interact.

​

Fundamental Architecture

The following architectural components are required for all deployments of the Anchor Platform.

​

Client

The client is an application, such as a wallet or remittance sender, that acts on behalf of a user and makes requests to the system. Clients make requests to the SEP server component of the Anchor Platform using sets of standards called SEPs (Stellar Ecosystem Proposals).

​

SEP Server

The SEP server is a client-facing server and therefore needs to be accessible from an external network. The SEP server processes user requests and manages the state of transactions they initiate. When the SEP server needs to provide information it doesn’t have to the client, such as the exchange rate for an asset pair or the KYC status of a customer, it makes synchronous callback requests to the business server and returns the information in a SEP-compliant format.

​

Business Server

The business server is a service that you (the business) must implement to connect the Anchor Platform with your internal systems. The business server responds to callback requests sent by the SEP server, such as requests for a quote, receives events sent by event service, such as notification of a received payment to your Stellar account, and provides updates to the platform server when off-chain events occur, such as the initiation of a bank transfer to a customer.

​

Platform Server

The platform server is an internal component. It should be hosted in a private network and should not be accessible from the Internet. This server enables the business to fetch and update the state of transactions using its API.

​

Database

The Anchor Platform uses a PostgreSQL database to store Stellar events and entities. It is primary used to store transactions.

​

Kafka

Kafka is used as the messaging backbone for the Anchor Platform, facilitating communication and event-driven interactions between different components. It allows components like the SEP server, business server, and event service to publish and subscribe to transaction and payment events in a reliable and scalable manner.

​

Complete Architecture

In addition to the components described above, the Anchor Platform includes several other components that offer additional functionality. Your business can chose to which of the additional components to use, but the diagram below visualizes the architecture of the system if all components are utilized.

​

Event Service

The event service enables the Anchor Platform to send HTTP webhooks to registered clients and your business server when the state of transactions change, removing the need for clients and/or your business server to poll the Anchor Platform’s APIs. It works by reading events from published to a Kafka topic by the other Anchor Platform components. Read more about using the event service.

​

Payment Observer

The Payment Observer monitors the Stellar blockchain using Stellar RPC or Horizon, automatically detects payments related to the business, and updates the corresponding transactions in the Anchor Platform’s database. If you also use the events service, payments to your accounts will trigger a HTTP callback made to your business server. If you already have a solution for monitor payments to your Stellar accounts, such as an integration with your exchange, Horizon, or RPC, then this component is not required, although your business server will need to notify the Anchor Platform when a payment associated with an Anchor Platform transaction was made to your one of your Stellar accounts via the Platform API.