This article is written for interview / documentation purposes. If you have any questions about the content please contact me.

Maple started as a B2C product, as a service where users can purchase products and get technicians to install them in their homes.

Later, this evolved into a completely different (B2B) product (eventually a B2B2C), that enables companies manage their workers quickly and efficiently through a work order system.

It's a complicated product, but in essence it helps the company be more efficient scheduling work for their workers whilst giving top-down visibility to managers. Despite the name of the company, there was no AI involved.

Tech stack:

  • Golang | API
  • Ionic, Angular and Cordova | App
  • Angular | Website

Some remarkable features

Every client has their own instance

This was a fairly important decision made to facilitate geographical distribution of clients, and also suit the needs of those who wish to self-host their data. Having a monolithic server for all clients would prevent us from growing if this was required in the future.

After client sign up there's a job that creates the environment for the client:

  1. Database is created with user role of the client
  2. Sub domain allocated (via cloudflare API)
  3. Configuration is mapped for the client
  4. New deployment is created through kubernetes API

Even though this worked very well, there was still one big hurdle in a fully distributed system. We had a requirement that enabled users to belong to multiple teams.. Another issue was during login, since there had to be a central point from which the user finds their server instance. This resulted in us having a table of all users. Naturally this lead to some email conflicts and weird rules for password management.

Job assignment to a contractor

In maple's system, all contractors had to be on our system. Clients could partner up with each other using a handshake method, then assign jobs and monitor them from their own system. During the handshake, the systems create their own API keys and exchange them. There's a potential issue if the server was behind a restricted firewall, it would not be able to communicate to contractor's servers.

It's nice feature that allows for some recursion; a client assigns it's contractor a job, who assigns it's contractor a job who assigns it's technician a job. Updates then flow upstream to the source - API's talk to each other.

Database architecture