Scaling Financial Reporting at Airbnb

If this is generalizable, and it looks like it is, it would be pretty smart to spin this out as a new company, make Airbnb the company&#x27;s first customer, and go after Oracle&#x27;s financial products.<p>(Disclosure: I used to work at Oracle on Financials Cloud.)

There seems to be an accounting equivalent of Greenspun&#x27;s tenth rule:<p>&quot;Any sufficiently complicated financial reporting system contains an ad-hoc, informally-specified, bug-ridden implementation of double-entry accounting.&quot;<p>It&#x27;s such a powerful yet simple way of thinking about money that anyone who builds a billing or accounting system should be intimately familiar with it.

&quot;Going from imperative programming to functional programming has been a powerful paradigm shift for us to think about financial processing and accounting. We can now think of this system as a straightforward actor&#x2F;handler system rather than getting mired in complicated SQL-join logic.&quot;<p>Though whether SQL is a functional language (or a programming language at all, if you&#x27;re talking ANSI SQL) is a subtle question, I would at the very least not describe it as a traditional imperative programming language. I think this is an important distinction for the article because, contrary to what this article suggests, I&#x27;ve found SQL to be quite helpful for understanding functional and declarative programming concepts. That said, it might be a lot easier to express the types of tasks in the article as straight-forward functions rather than getting wrapped up in all this set-based talk in SQL.

This is very interesting, but I would love to know more details. Are they using something like Amazon Kinesis or Kafka to send events and handle missed events? What serialization format are the messages? How do they manage keeping the schemas of the events in sync?

At my company we built accounting on top of Xero.com API. Even at our small scale we&#x27;re already busting their capacity. Some reports can&#x27;t even be generated anymore because we have too much transactions.<p>This post is a fascinating outlook of how things can be ran at big corp. I always wondered how big companies did accounting. This stuff can&#x27;t be outsourced since it&#x27;s so tightly coupled to your business logic.<p>Is there any <i>tech</i> conferences geared toward this stuff?<p>Any accounting saas that can scale indefinitely? As opposed to Xero?

This is great, thanks for the writeup! We are actually building something quite similar. We have a rough landing page up at hireross.com. Airbnb folks, I&#x27;d love to chat if you&#x27;re up for it. Just to learn more. email is at the bottom of the landing page.

Did you consult your auditors through this? I would expect their answer to be something along the lines of &quot;Spark? Scala? We don&#x27;t think we can trust this so we&#x27;ll need to do a full audit.&quot; versus &quot;Oh, you&#x27;re using SAP, ok.&quot;

„...On the date of the reservation confirmation, we have a guest receivable of $100, and a future host payable of $90...“<p>The one thing I hate about AirBnB.... Looking to rent a nice place for 10k 9 months in advance? Ok...we&#x27;ll charge it RIGHT NOW.<p>Why not do it like Amazon and charge when the package is shipped (trip date has arrived)? I get the cashflow thing but come on... (100 bookings and counting...)

I&#x27;ve previously worked with enterprise financial systems, and most of what was described here was standard functionality, or would be customisable to do so without too much effort. I would have loved to have heard more about whether they evaluated traditional ERP systems and why they chose to build their own event sourcing system instead.

I&#x27;m worn out on articles dissing the performance of SQL databases without quoting any hard numbers and then proceeding to replace the systems with no thanks of development in the latest and great tech. I have nothing against spark, but I find it very hard to believe that alarm code is now readable than SQL. In fact, my experience is just the opposite.<p>AirBnB is using an extract, load and transform architecture. No mention of the hardware, data through put, whether they have a message broker&#x2F;queue to ease the burden of peak volume but work.<p>I have a strong feeling that they could have 1.) Kept the system exactly how it is and done some performance tuning. But that&#x27;s not sexxy anymore. Things are just supposed to scale. Which brings me to<p>2.) Moved transformation logic to its own server or multiple servers using a message broker and queue to aid the transfer of data between systems. It would have been more readable and could have been done in a mo the or less.<p>In summary I believe they should have put some effort in to keep SQL. Especially for the purpose of accounting because spark does not lend itself to readable logic.

Alice, do you recognise guest receivables the day a booking is made, not the day after check-in (&quot;services rendered&quot;)? If that&#x27;s true, not sure if this is correct, i.e., this event doesn&#x27;t seem to meet the asset recognition criteria... My intuition would tell me Dt Accounts receivable - Cr Revenue on the day after check-in.

This new system that uses events looks more flexible since it is decoupled on the application logic. I think the downside with this one is that the new system has a lot of moving parts. Also, changes in logic&#x2F;new events must be communicated and should be supported before the main app is put into production.

Is it really that big that we need to talk about &quot;scaling&quot; it? 4-5 hours of processing time is a lot... I mean how many transactions would they do on a normal day?

tldr; They built an event&#x2F;messaging system. When an event occurs they broadcast that event with meta data. (EG. event: reservation_booked, meta {..}). Before they tightly coupled reporting sql inside the business logic.