Concept

Policy API performance is critical for policy transactions.

Depending on different business scenarios, the InsureMO platform provides different sets of APIs or configurations to optimize the API performance while meeting the business requirements.

Overview

Overall Decision Chart

InsureMO Support

This document provides a general introduction on the areas which can help to improve the API performance.

For some of the choices, InsureMO platform has a default setting which balances the system performance requirement and user operation usability, although actually there are indeed multiple choices to provide.

If you have some special scenario or especially high PFM requirement, it’s suggested that you can read through all the document and contact InsureMO support team for further evaluation. InsureMO team might help you to change some of backend parameter to meet your performance requirement.

Policy Persistence API Optimization

Storage Structure - Standard and Simplified

There are two ways to store the policy data in the backend database:

1. Standard storage - store entire policy data into 10+ tables in a relational way and not best performance friendly
2. Simplified storage - store entire policy data into a single table with big Json and best performance friendly

Now there are four scenarios in which simplified structure can be used:

• Benefit

The overall performance especially the stress limit is considerably improved (+50%) while the speed of individual API without pressure is improved slightly (+10%).

• Limitation

Because the data storage structure is loosened, the method to extract reports and conduct SQL data patches based on transactional DB structure is greatly impacted. You must resort to other modernized reporting tools such as DataMO to extract reports and use database JSON API to conduct data patches.

Below is a comparison table about two options:

Search Method - Elasticsearch or DB

With our default proposal structure, all policy key information will be synchronized to Elasticsearch for storage as well.

• Benefit

By leveraging the powerful capability of Elasticsearch, you can perform all kinds of searches including fuzzy search or keyword search. Also, you can freely and flexibly extend the search criteria by using our index configuration.

• Limitation

However, because of the Elasticsearch synchronization, total API performance and TPS are reduced (30% on average) and there’s a bigger chance of instability when business volume becomes higher.

So Elasticsearch is not supported for our quotation/micro-insurance structure. Even for the proposal, we allow a separate configuration not to write to ES if performance is the key consideration for the tenant.

Without ES, you cannot use our default search API. However, our platform does offer some DB-level search APIs. These APIs only permit fixed search criteria, with a maximum of 6 user-defined search criteria allowed. No fuzzy search is allowed.

Adopt Separate Micro-Insurance and Quotation API

If your business transaction volume is huge, it will be better to use our quotation or micro-insurance API instead of a proposal.

• Benefit

1. They belong to separate microservices. Even if there are big volumes, any fluctuation of microservice will only impact themselves rather than other standard proposal transactions. Also, the service scalability can be more targeted.

2. System records of them are stored in separate schema/tables. You can regularly conduct DB-level housekeeping on those transactions while not impacting other standard transactions.

• Limitation

1. They are not Elasticsearch-supported. So no fuzzy search support and numbers of exact search criteria are very limited (platform fixed criteria + 6 user-defined criteria).
2. They are generically stored in a simplified structure, and the level of data patch and report extraction is very limited.
3. There’s an extra development cost to develop and test separate APIs rather than standard proposal APIs.
4. Some additional features like policy fees and proposal version comparison are not supported for these two microservices.

An explanation table is provided below to help readers to further understand the details of their differences.

Overall, if business volume is not high, proposal API can suit most of the business scenarios. However, if the transaction volume is high, especially for digital connections, it’s necessary to explore quotation and micro-insurance API for its high performance and response.

Adopt Separate Group Policy API

If there are any of the insured or scheduled lists that potentially can be very big (larger than 50), you must start evaluating the possibility of adopting a group policy solution.

Group policy because of its detached structure and batch/concurrent capability, will always have better performance than a single policy.

However, the development cost will be much higher to adopt a whole set of group policy APIs.

Policy Rating/Rule API Optimization

Disable Tracking Log

Now if you use our rating or rule engine, the system has the capability for you to conduct troubleshooting via tracking log to see the debug output of each step.

This is quite a useful feature if any user reports errors on rating or rule. However, it does have a performance impact (15% on rating/rule API and even more in high-stress situations) because of the frequent database interaction to save the large tracking information.

Your judgement will determine the priority between performance and troubleshooting. If you think performance is more important, you can contact our InsureMO support team to switch the tracking log off on production.

Rule/Rating Slow

Please further analyze the time within the rating/rule tracking and optimize it.

1. If it’s due to complex iteration logic, please try to minimize it as much as possible.
2. If it’s due to a big rate table/data table lookup, please check your configuration whether the index field has been set up or split the table.
3. Also, please remove all exception catches in the script.

Composite Rest API Optimization

Within client iComposer, if you are firing multiple platform APIs together, due to the network and authentication process, it will extra performance costs which will make the system slower.

When that happens, you can explore whether to combine multiple APIs into one platform API call by using our composite Rest API capability.

For more detail, see Composite Rest API guide.

Infrastructure Resource Optimization

Although we are all on the cloud, different cloud providers offer a variety of infrastructure machines to choose from, and these machines can have significantly different performance responses.

By default, our InsureMO team will subscript which machine is the best-suited to our client contract value and expected business volume/response timing.

If there’s any expected business volume/response timing change, you can contact our InsureMO team to further evaluate and expand the infra resource if necessary.