# Policy API Performance Improvement ## 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 ```mermaid graph TD A[Is potential no of any policy item list big] -- Yes --> G A[Is potential no of any policy item list big] -- No --> S1 G[Is the big number of policy item insured risk or not] -- Yes --> G1{Group Policy Risk
- Separate API} G[Is the big number of policy item insured risk or not] -- No--> G2{Group Policy Schedule
- Separate API} S1[Is need of DB level report extraction or frequent data patch
more important than performance] -- No --> S S1[Is need of DB level report extraction or frequent data patch
more important than performance] -- Yes --> S11 S11[Is DB operation needed for
issued policy only or include pending proposal] -- Issued Policy only --> S111{Proposal with Fast Proposal
- Default Config} S11[Is DB operation needed for
issued policy only or include pending proposal] -- Policy and proposal --> S112{Proposal with Standard Structure
- Separate Config} S[Is there a need for fuzzy search or flexible search
more important than performance] -- Yes --> S12 S[Is there a need for fuzzy search or flexible search
more important than performance] -- No --> S2 S2[Is there any high volume transaction which can be
separate from standard transaction] -- Yes --> S21{Quotation or Micro-Insurance
- Separate API} S2[Is there any high volume transaction which can be
separate from standard transaction] -- No --> S22{Proposal Without ES and
with Fast Proposal and Fast PA
- Separate Config} S12{Proposal with Fast Proposal and Fast PA
- Separate Config} ``` ```mermaid graph TD L[Is performance more important than need of production rating/rule log] -- Yes --> L1{Switch off rating rule tracking
- Separate Config} L[Is performance more important than need of production rating/rule log] -- No --> L2{Switch on rating rule tracking
- Default Config} ``` ```mermaid graph TD L[Is project budget more important than performance] -- Yes --> L1{Keep Existing Infra Resource
- Default Config} L[Is project budget more important than performance] -- No --> L2{Increase Infra Resource
- Separate Config} ``` ### 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: | | Proposal - Before Issue | Proposal - After Issue | Quotation | Micro Insurance | |-------------------------|------------------------|-------------------------|-----------------|-----| | Standard | Yes | Yes | No | No | | Simplified | Yes - Fast Proposal | Yes - Fast Policy or Fast PA | Yes | Yes | * 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: | | Performance w/o Pressure | Performance with Pressure | DB Report | Data Patch Script | |--------------------------|---------------------------|-------------------------------------|-------------------|--------| | Standard | Good | Good | Medium | Medium | | Simplified | Better (50ms improvement) | Excellent (Higher TPS and Response) | Harder | Harder | ### 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. | |Elasticsearch | DB Search | |-----------------------------|-----------|------------------------------------------------------------| | Applicable | Proposal | Quotation, Micro-insurance, Proposal (With Special Config) | | Transaction API Performance | Reduced | No Impact | | Fuzzy Search Allowed | Yes | No | | Search Criteria | Dynamic | Fixed + at a maximum of 6 user-defined | | Search Performance | Best | Good | ### 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. | Characteristics | Proposal | Quotation | Micro Insurance | |-------------------------------------------------------------------------|--------------------------------------|------------------------------------------------------------------|-------------------------------------------------------------------| | Numbering generation | Proposal Number/Policy Number | Quotation Number | Proposal Number/Policy Number | | Basic behavior | Persistence | Persistence | Persistence | | | Calculation/autoUnderWriting | Calculation/autoUnderWriting | | | | Issuance | | Issuance | | API response | Good | Excellent | Excellent | | Search Method/Statistics Support/Search Criteria | ES/Yes/Configurable - Fuzzy | DB/No/Fixed - Exact | DB/No/Fixed - Exact | | Data storage | Simple JSON or standard table structure | Simple JSON | Simple JSON | | Other Behavior | Standard Endorsement | N/A | Micro Endorsement | | | Multiple Proposal Version | | Summary of Micro Policies for BCP/Claim | | | Submission | | | | | Policy Fee | | | | Need to pass all policy element IDs and version sequences for persistence | Yes | No | No | | Business scenario | Standard transaction - 95% | Digital quotation transactions with huge volume and high-performance demand | Digital issuance transactions with huge volume and high-performance demand | | Scalability | Standard | Excellent | Excellent | 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. ![pfm_check_tracking](./image/policy/pfm_check_tracking.png) ## 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](https://docs.insuremo.com/gi_insurance_service/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.