Here is a very simple programming exercise that even a beginner Haskell programmer should be able to complete in a few minutes: given a list of Ints, can you produce a cumulative sum of those integers? For example, if we had the list [2, 3, 5, 7, 11, 13], we want to have [2, 5, 10, 17, 28, 41].

Since the very beginning, we have always used shake. The first commit that introduces shake was back in November 2014. Throughout the years, our build system went through one major refactoring in 2016, when we successfully used Shake’s ability to keep track of non-file dependencies to keep track of our Docker images and containers.

Prelude

It has been nearly two years since our former CTO Arnaud Bailly posted his widely read article on Capital Match’s architecture on November 16, 2015. Since then, we have written about our architecture several times, but they were all were intended for an audience of investors or business people, which necessarily means a high concentration of buzzwords, fancy graphics with impressive-looking diagrams and flow charts, but with a dearth of actual technical details. Today, however, I will write about Capital Match’s architecture for a technical audience. I will largely follow the structure of the original post so it helps to read that post first.

At Capital Match, we run Haskell in production. That means taking GHC-compiled Haskell programs and running them on the machines that our nginx reverse proxy connects to. They listen on port 80, and the reverse proxy forwards requests to them. It’s a fairly standard setup.

Capital Match is a market-leading peer-to-peer lending and invoice financing startup for SMEs in Singapore, and we are in the process of expanding to other countries. In this blog, however, we will take a break from our awesome and rapidly expanding business and focus on some of the technologies behind Capital Match.