Insuredx-Research

UPDATE: after research on Database systems, I've found that even SQL database will work just fine on all the data that we have
Clearly demarcated available technologies with the ones that are required to be built

Given Conditions

• Currently 90% of all insurance contracts are handled by agents and only 10% are handled online.
• The given month is October.
• Currently the system that is available is only able to process 500 transactions per second(TPS) and there are 10000 units of insurace sold monthly.
• The CEO has demanded all of the transactions and the system must grow by atleast 3 times to handle the demand.

Problems

1. CFO wants to reduce cost of the system.
2. Sales team wants to move 90% of the business online.
3. The business operations team will be reduced to 50% of the current capacity
4. All of these changes must be integrated into the system in 30 days and the current month is October.
5. The system must be ready with UAT, SIT and VAPT by the next quarter.

What all needs to be decided?

• Should we build a new system or should we work on the current system?
• What are the functional requirements that need to be implemented?
• What are the technical requirements that need to be implemented?
• What are the business requirements that need to be implemented?

Proposed solution

Assumptions

• These components in the system are already available and ready to use
  • Data of the insurance policies that the company already has (sql as the data is is vertically larger with data types like string for policy content, number for amount)
  • Data of all current users
  • A premature Insurance purchase module
• However the system is not cloud native and incapable of handling 3x loads (why ? the system runs on servers hosted in the insurance office facility and runs an ancient language(COBOL) that does not follow the 15 principle of cloud nativeness like easy maintainability, scalability, upgradibility, etc)
• Application is Monolithic: For making a small upgrade we will have to deploy the entire application again

Existing tech:

• Frontend purchase: Vanilla HTML, CSS, Javascript
• Hosting: Currently on-premise baremetal servers
• Backend: COBOL
• Database: SQL (perfect and ready to ship)

Functional Requirements and Availability

The ones ticked are the modules that are currently available

• User Data Module
• Insurance Data module
• Insurance purchase module
• Insurance recommendation module
• Quotation Engine Module
• Claims processing module
• Customer Support and Query Resolution Module - (Service module)
• Agent platform module - which will be similar to the customer module in most ways however given that the agents are versed with the company and insurance schemes, module will be trimmed and adjusted for quick purchase and bulk purchase
  • illustrations (long term plans for clients)
  • reminder modules
  • commisions and payments
• Advertising module for automated contact to users through emails and phone call regarding new insurance schemes - (Campaign module)
• Content Management System (CMS) for marketing and homepage of the insurance web page

Flow of buying an insurance policy

Technical Requirements

Proposed Tech with reasons:

• Frontend: Reactjs

  • React is a JavaScript library for building interactive user interfaces.
  • Why current is not correct? The vanilla frontend currently used is slow because every click required a new webpage to be loaded, there is a lot of redundancy in HTML and Javascript code
  • Reactjs uses the idea of single page application which makes loading process as smooth as possible as not all elements have to be rendered every time an action is performed
  • Reactjs also makes frontend modular as each component is treated seperately from the rest of the system
  • Repetive and redundancy in coding is minimised as the build engine takes care of it

• Hosting: Migrate from on-premise to Azure as this help remove the lower level of abstraction from a developer/Sysadmin of maintaining the server and increase the total uptime of the system, make the system more efficient and deploy content faster.

• Backend: Nextjs

• Database

  • As the data is highly relational the database we use is SQL for all purposes it gives us the benefits of ACID
  • ACID:
    • Atomic: Entire transaction takes place at once
    • Consistent: Schemas for our database tables are highly consistent
    • Isolated: Lot of insurance transactions take place however one purchase doesn't influence other purchases or users, hence its isolated
    • Durable: Even incase of a system failure once a transaction takes place its written to nonvolatile memory hence it doesn't get lot

• CI/CD

  • This is one major missing point in the current system which is very essential to make the system cloud first.
  • CI or Continuous Integration is tech where every push to a repository triggers actions that can be defined by the development team. TDD or Test Driven Development is where one creates tests that evaluate the requirements of our Insurance platform before actually creating the platform. Now whenever we make changes and push our code, the test can do security and functional checks on our code and give us updates on the performance of our applicate
  • For the purposes of our Insurance platform, I suggest we use the GitHub actions tool for CI, we can even use the ones provided by LayerCI, etc
  • CD or Continuous Delivery is the tech where we can release our platform continuosly without downtimes with new feature as they're ready. CD can also be used when we want to test a feature like insurance recommendations with only a subset of people

• Microservices

  • Frontend
  • Backend
  • Database
  • Messages
  • Networking

  All are running on their own unit of application so upgrade doesn't have to take the whole system down

• Containers:

  • Use containers to make multiple applications running together on servers
  • Autoscale on requirements
  • Use Kubernetes orchestrators as it helps in deploy and manage containers dynamically