Engineering at Pasarpolis

Pasarpolis is the number one insuretech firm in south-east Asia. We sell differentiated insurance products in the South East Asia region. Insurance penetration in the SEA region is low.

Indonesia’s Gross Written Premium was 84 Trillion IDR — 2.77% of the population (250 million) [Reference 1]

We are increasing the reach by educating the populace about the usefulness of insurance through various channels and platforms where customers are already present en masse, like Gojek and Tokopedia. In addition to that, our portfolio of product offerings and the price points we offer them at, make them accessible to everyone.

We offer a comprehensive portfolio of products that span across the following sub-domains under general insurance — travel, health, automotive, credit, delivery, and gadgets.

Our product offerings are -

1. Time-sliced — We sell event-based insurance. E.g. Your cab ride from the pickup point to your destination is insured for any accident that may occur. The policy is valid from the beginning of the ride until the end.
2. Price-sliced — We slice the benefits to give our customer only those that matter, at an affordable price. E.g. You can ensure your old or new mobile-phone’s screen against cracks.

Ecosystem

There are 3 key entities in the micro-insurance domain — Partner, Insure-tech, and Provider. Partner has a platform where the insurance product is sold. They have access to retail customers across various domains. Traveloka, Gojek, Tokopedia, Homecredit, and JDID are a few of our partners. The provider is the one underwriting that product. Simas, Allianz, and Kresna are a few of the providers we work with. Pasarpolis is the tech layer between the two. We define the product by assessing its risks closely with the provider and the partner.

Provider’s role -

1. Underwriting — Deep understanding of the risk-based on decades of data on traditional products
2. Settlements — Pay the disbursement amount when a legit claim is received

Partner’s role -

1. Gojek market reach — 30 Million monthly active users in Indonesia [Reference 2]
2. Exposure to the underserved market — Make the pie bigger

We complement Partners and Providers by bringing innovative technology. It helps partners provide insurance to all their customers from within their platform. It helps providers quickly roll out products. We give them a better understanding of the risk of new and innovative insurance products.

Core Business Processes

1. Policies — Sell insurance policies
2. Claims — Accept claims, do validations/checks, communicate with the customer
3. Operations (horizontal to both the above) — E.g. Activate a policy, reach out to the customer, review a document, trigger the claim settlement.

Application Infrastructure

Our entire application infrastructure is hosted on the cloud. We are Python 3 + Go + MySQL shop, hosting most of our services on Google Cloud Platform. We are committed to building and maintaining a very flexible and scalable application infrastructure. Therefore, each business process is implemented as an independent micro-service. Most often, they are implemented using the Django framework. These microservices interact with each other for various business processes and transactions. We leverage Google’s managed services to build our apps. A few of those are -

1. Google Cloud Storage — Bucketed storage layer — Any and every file is stored here
2. PubSub — Features from RabbitMQ and Kafka— Message queueing — Helps services asynchronously communicate with each other reliably and smoothly
3. MySQL 5.7 — Transactional database — Store and retrieve application data
4. Cloud functions — Lambda functions for server-less computation, often on files stored in Google Cloud Storage
5. Kubernetes — Pods and container orchestration on Google Compute
6. G Suite — Authentication and authorization across all services

Each application is implemented as a Microservice. These microservices interact with each other to execute the business workflows in either synchronous or asynchronous manner depending upon the action to be performed.

In most situations, where the payload size is not high, we exchange information between services in JSON format.

E.g. Synchronous — REST API — The requesting service wants an immediate response. We don’t want to keep the user waiting. An example of that is fetching the policy information of the user when she wants to raise a fresh claim. Downside — The responding service needs to match the rate of response to the rate at which requests are created and received.

E.g. Asynchronous — PubSub — Service writes the message in the topic, the subscriber based on its bandwidth listens to the topic, consumes that information, that message once read, disappears. Upside, it allows the services, the one writing requests and the one reading those requests, scales independently. There may not always be a need for a service to respond immediately if it isn’t mission-critical or doesn’t have the need from the user experience point of view.

Team

We use JIRA for project management and Gitlab as the version-control system/code repository. We use Confluence as our documentation platform. We follow the 2-week sprints. It’s a hybrid agile strategy that works the best for us. The more mature projects are the most agile, on the other hand, the fresh product releases and experience launches are the least agile. We do the following types of meetings to stay focused on our objectives -

1. Backlog grooming — 3–4 days before the sprint begins
2. Sprint planning — 1 day before the sprint begins
3. Daily huddles — Twice/once daily, 15 minute connects
4. Sprint retrospective — Last day of the sprint

The size of our tech team is 55. We collaborate closely with the 8 members of the product team. Our tech team is grouped into Chapters and Pods.

1. Chapters are permanent entities. Their lifespan would be upwards of 6 months. Pods are created to release a feature-set that solves a business problem, they cease to exist after ensuring a successful release. Their lifetime could be between 2 weeks up to 6 months.
2. Chapters are led by chapter-leads who are technical experts of that domain, for example — React. Pods are led by the Product Manager accountable for the feature-set release.
3. The size of a chapter is large. The pod size will not be greater than 8.
4. Chapters have experts in one technical area. The pod has the combined full-stack skillset with members from across multiple chapters.

Chapters are -

1. Auxiliary services like claims and notifications (backend)
2. Policies (backend)
3. Integrations (backend)
4. Frontend
5. Mobile
6. Data Analytics and Insights

Pods are -

Like Customer 360 — Customer 360 application allows an operations executive to fetch relevant information for the customer — It had members from all chapters to see the set of features through to production

Pods are analogous to Squads in the referred article. [Reference 3]

Routines

1. Documentation — We place the utmost importance on documentation and taxonomy management. This is the second thing, after code, that helps us solve business problems without being dependent on individuals who participated in the specific releases in the past. Further, it helps smoothen the communication between teams that are geographically separated.
2. Communication — Slack is the team collaboration tool. It works really well for us. Milestones are communicated over emails, but everything else happens through Slack. Besides that, it gives us the ability to integrate a lot of our managed services to send notification over Slack.
3. Release Management — Continuous integration and delivery of Kubernetes containers are setup using Gitlab runner.
4. Environments — We take the same piece of code from testing to staging and finally to the production cloud environment. We have an autotest cluster for automated testing which replicates the production cluster. It spawns automatically and then spins down once done. It gives us the ability to quickly run regression tests.
5. Site reliability — The following put together give us the complete picture of how our various services are performing, and if we have to look into something urgently -

• Sentry — It aggregates errors from across the stack in real-time and throws them as Slack messages and emails to the chosen channels
• StackDriver — Logging, monitoring, and profiling — Google Cloud Platform’s observability suite that helps us keep our applications performant and available
• Metabase pulse — Daily scheduled reports that give us a peek into the historic data, letting us know if things are working as expected over time

References

1. Reference 1 — http://aaui.or.id/wp-content/uploads/2019/10/INDONESIA-MARKET-UPDATE-y-2018-2019.pdf
2. Reference 2 — https://asia.nikkei.com/Business/Startups/Gojek-aims-to-grow-non-Indonesia-users-to-50-of-operations
3. Reference 3 — https://medium.com/@achardypm/agile-team-organisation-squads-chapters-tribes-and-guilds-80932ace0fdc