AdHive advertising platform introduces improved non-blockable billing concept to support payments within the system.
As blockchain based businesses continue to scale, the question of their functionality and scalability arises. Billing is a critical business element for systems with transfer of any units from one user to another, no matter if we are talking about fiat money, bitcoins or internal tokens. AdHive developers have addressed the issue with their non-blockable billing application.
As you already know Adhive is the first platform that fully automates ad placement with influencers. Effectively, placement of the ad with a thousands influencers takes as much time as placement with only one. In this case thousands of transactions are to take place, that is why an effective billing system is a must.
We can not use third-party proprietary or open billing systems because of the specific requirements that exist in the AdHive system. That is why we aimed at building a distributed system focused on scaling within the project, thus way higher requirements were attributed to the billing.
Now, those of you hoping for a relaxed two minute read may take a deep breath cause there is some serious system architecture talking ahead. As a result of the comprehensive internal study, the concept of non-blockable billing was born. In this system each transaction on the account is either increment, or decrement to the previous state of the account.
When you need to transfer money from one account to another account, a “Payment Order” is created, then it is verified and a “transaction” is created on the basis of the “Payment Order”. Based on the “transaction”, two transactions are created on the accounts (“Increment” and “Decrement”).
As you can see, the idea is extremely simple.
This approach allows
- check the entire chain by repeated test generation of elements
- Distribute data evenly among hosts
- Improve performance by adding hosts
It has an advantage worth mentioning: at any moment of time the account status will represent the sum of operations, which allows getting rid of account blocking or deadlocking in the build. This allows us to perform operations infinitely quickly because to increase the production we only need to add a server.
Since abolishing unauthorized changes in account balances was one of the primary aims, this innovation, combined with blockchain, made it achievable.
Depending on the project’s scale of operations, there are different requirements for the billing system. General set includes an ability to perform basic account operations like account creation, increments and decrements, balance and history retrieving, and more complex tasks like group operations (decrement over one and increment over the second, e.g. actual transfers between accounts) and a set of non-product underlying requirements, like analytics and lack of uncontrolled history change.
Additional functions relay to proportional performance, volume scaling, continuous data backup with an ability to restore state integrity at any moment, ability of transforming storage methods without stopping work, no single point of failure regime, ability of carrying out maintenance works without degrading basic billing functionality and lack of degradation of non-logarithmic nature at an increase in the number of records.
AdHive’s solution is based on a detailed implementation architecture designed to meet the extended list of requirements.
In essence, AdHive billing is divided into 3 layers, with a security layer on top of them:
- External services;
- Compute-cache services;
- Persistent data storage.
External services include all the services that provide interactions. To avoid cluttering the API, 2 subtypes of “External services” were introduced — public and private.
Public external services are: APIs for managing mass transactions, integration services with external payment systems and exchange platforms.
Private external services include integrations with non-product systems, like Administrator Interface, Repair tools and Business Intelligence systems.
All messages received from “external services” enter the security layer, which performs identification and authentication of the source of the message and authorization of the access initializer.
Compute-cache services are used to perform the operations on.
In the case of correctness, messages associated with data changes are transmitted to the Storage Service, which stores messages to prevent loss of the message when the external system is running asynchronously. If the message is not related to data changes, it is transferred to the computational In-Memory Data Grid solution.
For providing highload sustainability Apache Ignite was used as In-Memory Data Grid solution under the hood.
Grid tasks:
- Converting incoming transfer requests into an operation on the account, sending it to the storage layer, and updating the internal cached aggregates;
- Providing quick access to hot data;
- Ensuring the implementation of complex operations associated with the transformation of data;
- Providing basic reporting functionality;
- Providing triggers for notification of external systems (for example, running out of money event or identification of fraud).
Both Story And Storage services were designed to store the data. While Story service works with incoming messages (e.g. transfer requests) only, Storage service consist of a set of different repositories, which are used to store different types of data — raw data, increment and decrements only, aggregated data, indexes, etc.
The given implementation has a number of advantages:
- Segment scalability — to increase performance or increase data capacity, only part of the system needs to be scaled;
- Resilience to failure of entire storage segments — If the persistent storage is lost, it is possible to continue working with the grid. If the grid is lost, it is possible to provide basic functionality with a persistent layer;
- Atomicity of updates. In view of the division into atomic services, it is possible to isolate the life cycle of software solutions without the need for a common context (development, testing, commissioning, updating, replacement);
- Avoidance of unauthorized data changes, even with access to the repository. Thanks to blockchain it is impossible to change or add previously recorded data;
- Maintaining low response times under high strain thanks to the presence of hot data in memory;
- The ability to prioritize operation queues over the storage structure.
We are sure that AdHive can make another breakthrough mixing classic high-performance billing and blockchain. Already our implementation is soliving most of the difficulties of the platform, providing:
- high quality performance
Now we have 2 dicentres in different regions. For billing purposes, 3 servers are used in the Alfa data center and 2 in the Beta data center. At a replication level for each Data Center 2 (2 copies of data in each data center). We have a performance of 48K and 40K operations per second (The difference is due to the different servers used. At the moment, the performance increase is a multiple of the number of servers) - simple scaling up
Expansion of any of the existing data centers occurs within 12 minutes after receiving the server. Adding a new data center takes about 20 minutes to start and 50 minutes to complete the data synchronization. Unlike typical billing storage schemes, an increase in the number of servers does not need a manual modification of the key storage card. It comes from the box. - easy integration
The presence of a simple rest-api allows you to add a new payment scenario per day. This is achieved by the fact that billing can work in dev mode, which provides the developer with a very convenient local billing instance. - safety of operations
Unique backup synchronization strategy allows for unlimited copies to expect to write only 2 data sets in one data center (this is very fast), lack of content on the keys allows you to synchronize the data centers asynchronously.
As the next steps of AdHive Billing development we plan to:
- increase the saving rate by 1.2 times by adding preliminary saving steps
- provide the ability to add servers with a rating of performance, which will allow even more efficiently to increase the load
- integrate with blockchain systems and various payment systems
- expand transaction confirmation capabilities
- expand the available methods of accrual of funds
- implement a full-blown blockchain — on the basis of aggregates and verification of aggregates
- introduce hedging instruments
For any startup, it is important to respond quickly to business challenges. That is one of the reasons why such companies as Amazon and Netflix have grown up from niche players to the leaders of IT industry. AdHive billing system was born and is developing under similar conditions. We believe that our system will become a new branch of blockchain development and one day will become a common corporate solution.
Official links:
