Today we discuss another System Design question. We have been covering data architectures and store services. We now look at Payments system which is central to most stores. We consider one such payment platform that has become truly global as it helps travelers throughout  the world. Airbnb is a global onlinemarketplace where payments are one of the largest in-house payment systems.

Airbnb initially managed payments offline. It was done in the form of cash exchange and travelers and their host would often find themselves in awkward position if an ATM was not around. This is how the payments infrastructure was required as part of the Airbnb system. Bidirectional transfers were not immediately available in off the shelf payments so a solution was implemented through paypal where the host would receive a paper check.

Writing checks by hand does not scale as PayPal usages grew, so support for credit cards and automated bank transfers was added. This was added still difficult to connect the global travelers. For example, European guests in the United States had to pay an additional conversion fee. Credit cards were not so common in some countries. And hosts outside the United States did not want US dollars in their PayPal account. Brazil was particularly notorious for numerous competing payment networks which do not work internationally. Support for local credit cards and cash transfers were both required during the Rio Olympics. So a new payment form was introduced called Boletos which was an invoice for the amount owed to AirBnb. Guests could take the Boleto to their bank and pay the invoice and the reservation would show confirmed as status on AirBnb once the payment was received. By allowing Airbnb to be the facilitator of payments, the host and the guest were both freed from the hassle of direct exchange.

Boletos introduced asynchronous payments which now expanded support for new payment methods. In the beginning payment integrations were each done from scratch and added to the system. This presented more software maintenance as integrations expanded. Initially, ActiveRecord models were  used with Rails to access the database. The payment objects were mutable and there was no change tracking enabled in the application. Consequently triggers were written in the database to capture the changes in a separate audit trail table. This custom change tracking and reverse-engineering of audit trails required elaborate SQL queries. When these queries grew more and more comples together with a dramatic increase in the volume of records, the reporting database started groaning for performance improvements.  All these three issues of new integrations, billing and payment interface and reverse-engineering from audit trails were limiting. So a new platform was written which involved three standalone systems – a backend system that processed bills, a gateway that allowed payments to be processed by external processors and Kafka that streamed these two events to financial pipelines which enabled reporting using Spark.

This case study is interesting to compare  SQL + MSMQ with Kafka and Spark. In the payments mechanism study at a retail company discussed earlier, we saw how events flew into message queues which were handled by dozens of processors and sometimes in series to update relevant records in transactional databases while reports would flow from a warehouse that drew data from operational side using traditional and perhaps classic methods. The capacity was increased based on clusters for queues and databases separately.  Since the methods were traditional, their migration to cloud based services was well understood.  The Apache stack is also portable and can run in a variety of modes from standalone to cloud and with a variety of data sources. Public clouds offer support for both open source and commercial stacks in addition to offering their own cloud native data pipelines and analysis services. The Airbnb method highlights standalone systems which can be deployed anywhere.
Courtesy : Airbnb blog
#codingexercise
In yesterdays coding exercise, we counted based on the number of subarrays sums that had the same modulus
we can also give counts of all possible subarrays that don't have a sum divisible by K

Get count of subarray divisible by K 

int GetCountNotDivByK(List<int> A, int k) 

{ 

var mod = new int[k]; 

int sum = 0; 

for (int i = 0; i < A.Count; i++) 

{  

    sum += A[i]; 

    mod[((sum%k)+k)%k] += 1; 

} 

int result = 0; 

for (int i =0; i < k; i++) 

    if (mod[i] > 1) 

          result += (mod[i] * (mod[i]-1)) / 2; 

result += mod[0];

int all = 0;

for (int i = 0; i < mod.Length; i++)

{

    all += mod[i];

} 

return all - result; 

}