Architecture for Version 2.0

Disclaimer this is an unofficial post, I don’t guarantee the correctness or accuracy of the information I have provided below, please read and use as per your own risk. It is purely meant for educational purposes and needs to be corrected and scrutinized.

2.0 Webinar Summary

  1. Simplified and unified stack; removal of cookie and OAuth based authentication.

  2. All backend is available over JSON Rest API

  3. Modern Front-end using React/Angular/Vue/Ember.

  4. Deprecated OAUTH Provider; barong is no longer an OAUTH for identity verification, it is now an OAUTH consumer which still gives the ability to log in/log out/signup, etc. but it’s not available in Peatio. We can now use a long-range of login providers, we can use google, facebook, etc. Therefore Barong is no longer an OAUTH Server but a client for which we can use login providers.

  5. API appears like a monolith application & frontend developers get a unified API so they don’t have to worry about backend and don’t have to worry about routing.

Authentication Flow & Architecture V2

The JWTs are never sent directly to end-user and are no longer stored in the browser, only classic cookie session is used at the browser level, the session generates an ID which is used to clearly identify the user and hence cookie is the authorization mechanism, it uses an encryption that only the server can decrypt using keys.

Barong is used to identify using session ID & then verify the following:-

a) User table.
b) What is the status of the account (active/verified/blocked/etc.)
c) Does the user have an account?
d) What is the role of the user (Is he/she and admin, employee or customer…)

After Verifying User Barong will inject a JWT token into the HTTP header, therefore token is injected at only the header level. This protects all other API’s eg. Barong (Resource API), Peatio, Finex, Applogic, etc. with JWT.

This creates a double layer of protection: The first layer is a unique session ID if the user doesn’t have a session ID they provide login credentials to barong which opens a session ID & returns a cookie with the session ID. Ambassador queries your session ID to verify with Barong; once it has been verified barong injects JWT with a request for apps. The user is verified from the table.

Developers can create their logic and microservices in the language of their choice.

App-Logic;- is an example of microservices devs can also use serverless backend as long as it works with JWT.

Service-Oriented Architecture:

JWT is the standard way to authenticate as long as we stick to the standard of barong & configure Ambassador API gateway to map by adding new endpoints to global API and we can add any number of services from the front end side the API is seen only from Ambassador Side as react assets are on the left side of Ambassador.

Once react assets are complied they can be stored on CDN, the web browser makes a request using static HTML to Ingress/Nginx and downloads react assets and runs in chromium. The react asset then interacts with Ambassador API gateway, which is a unified API and doesn’t need to understand whether they are speaking to Peatio, Barong, Finex, etc. This has also solved the problem of instant logout because if in the web browser user deletes cookies and calls a delete session, it will waiver session ID so the session ID will be instantly invalid the cookie will be destroyed and so instantly the next call to barong will be blocked.

We can also create API keys so the user can go into their account and create a key pair. For Eg. the user has API secret connected with bots, and if from his profile he chooses to delete his key pair or disable it, it will be instant as it happens at the gateway level.

Ambassador API Gateway

It is very important to use the API gateway. Ambassador is an Open Source API gateway, it is part of a cloud-native Kubernetes ready type of gateway. This means we can connect to a lot of vendors monitor lots of statistics, limit the speed of API, we can add more security tools to Barong to complexify and add security tools next to Barong, Eg. Checking for cross-scripting attacks (XSS), we can add activity monitoring to block the user who seems to have suspicious activity, we can implement a lot of additional security features as the design provide a lot of flexibility and can be a very extensive architecture.

Barong V2.

The code was re-written from scratch using the latest Rails, completely removed UI & OAuth service in new barong, this was done with microservices in mind. It is more customizable as the front-end developers can create their UI for the admin panel.

Added support for Symmetric & Asymmetric API keys, this makes it easier for bots to trade on our platform & attract more users.

In Barong there are 2 main API’s one of them is called identity as Braong v2 is still an identity provider. Everything under identity starts with /identity and these APIs are not protected by JWT. /identity is about opening a new session: login logout signup and small features for authorization. authorization is a single API endpoint where all the traffic goes through a single authorization endpoint.

Improving security at endpoint goes everywhere & we can easily add more features as this offers a lot of flexibility. KYC flow is 90% the same as v1.9

The Design between Ambassador & Barong Identity Manager (Yellow & Pink) does not create a performance bottleneck as Ambassador Gateway has the ability to using envoy proxy which is a micro web server proxy which is superfast and scales to millions of requests per second. Ambassador is the code logic around envoy that can configure the whole thing.

The Pink Barong is the Authoriser API whereas the green barong is resource API which is protected by JWT, both can be scaled by deploying multiple instances.


Is a cloud-native ultra-performance API gateway built by Lyft(same as Envoy)

It makes it easier to configure & integrate.

Main Features we use are:-

a) CORS (Cross-Origin Resource Sharing for given service URL’s)

URL rewrite:- Replace URL prefix when routing to a service (a basic feature of API gateway).

API gateway Scheme.

It takes 4 lines of configuration to map a new service. Users can easily route & map new services as long as we comply with JWT. Ambassador is very easy if working with Kubernetes it uses Kubernetes Annotations.

This ensures we can use cloud-native tools some of the major tools are Prometheus, Grafana, Istio, etc.

Prometheus uses Grafana for resource graphing we can make charts for traffic for each gateway so we know how much traffic per gateway(Peatio, Barong, Front-end). We can use this to add API write limitation, short circuit ambassador requests for debugging or training. Istio is a security-hardened configuration tool to debug, block users (by country or IP), rate limiting, prevent-abuse, etc.


a) Full Power of Rubykube in a lightweight form.

b) Docker Compose Base: start it locally or run in VM.

c) Designed to be easy to use by front end devs. We get the power of Ambassador Gateway deployed right into Microkube, any time we want to build a front-end microkube is used. All our API is /api .

d) Uses already built containers so we no longer need to make sure which system we use.

e) Very easy to install well documented and has install Script (might be outdated) it should not take more than 10 minutes for full-stack to deploy.

f) It can be used for small production environments. (Soft release/Launch)

Note: Ideally for production, we use the database as a service & we don’t use MySQL in microkube instead configure to AWS based or MySQL in VM & eventually make a slave replication & backup system. It is important to secure our databases.

Microkube is not production Ready; we have to change passwords, remove database and most services in rake:services backend and reconfigure outside of microkube VM. We will need to build production-grade MySQL Redis Rabbit MQ with failover.
It is easier to configure using GCP/AWS with production containers using Kubernetes. AWS recommended tools are RDS & RabbitMQ we can provision these VM’s.

The purpose of Microkube is a fast and easy front-end dev environment & demo of the test environment.

We can also configure backups or virtual Disks & VM to avoid downtime.

Pros of Microkube are that it can from on VM which makes it easy & cluster is small and changes are easy to implement.

Cons:- it isn’t scalable to production we can use precautions mentioned above but it is better to use kubernetes.

Traffic comes in through traefik on port 80. The traffic then flows to frontend or ambassador if it is an API call Ambassador will route to Peatio, Barong, Ranger, etc. and they will use the backend services. Geth, RabbitMQ, Redis, MySQL, etc. for production we want backend outside of VM.

The scalability limit is in the size of the VM, one can also use a docker swarm to make a cluster possible, a 4 VM swarm.

If I have made any mistake in the above-mentioned information please to do point it out and provide a solution so that the community can have access to the most up-to-date information.

Warm Regards,


Is there a recommended split for services across multiple physical servers for a prod ready non-cloud deployment?

What do you guys provide to hook into the orderflow of a usd/eth for example?

1 Like