Microkernel architecture for insurance

Question

Working in insurance usually mean you need to deal with a myriad of rules and logic for rating, policy, and claims processing. These are steps in the insurance lifecycle.

Every insurance product (life insurance, travel insurance, etc.) generally follow the same flow above but with a big difference in the logic for each step.

Would it make sense to design an insurance system using a microkernel architecture?

This would mean that all parts of the insurance lifecycle (rating, policy, claims, etc.) is modeled in the core system, with pluggable components for every insurance product. This provides a very quick way to launch new insurance products by implementing a new plugin and adding it to the register.

Considerations and tradeoffs - I frequently see microkernels being used for monolithic applications. Does this mean that scalability & deployability of individual components is compromised?

Answer 1

When you are dealing with relative high scalability on the server side, you can work with a different kind of "micro". Microservices. Microservices allow you some flexibility:

• Each microservice would be self contained, so all UI, data storage, and set of endpoints are tailored for your policy type
• If the microservices have a "shared nothing" design, where state lives in the client or in the data store, then you can scale out a microservice that is being hit harder than the rest
  • Allows you to pay for what you need
  • Minimizes scaling costs
• API gateway makes the individual microservices appear like one API
• Simple load balancing rules makes it easy to route requests for all traffic
• Able to minimize the blast radius if a service goes down (i.e. one insurance product would be affected, not the whole application).

While you may need to do updates for your phone app, this approach will make it easier to adapt your web users. The obvious trade-off for microservices is the complexity it adds to your deployments. There are a number of services to help tame the process, such as containerization and orchestration (i.e. Kubernetes), it's still more moving parts. The flexibility is good, and in the long run might be the most appropriate choice.