Middleware Design


Insurance Claims Dashboard Case Study
Case Study Scenario
3m 55s
Start course

This course takes you through a case study of a real-world scenario in a financial setting. We'll go through how data gets processed, stored, and presented for an insurance dashboard. This dashboard displays all different types of insurance and is powered by an underlying database. So over this course, you'll both see some specifics for the industry vertical of insurance and some specifics on how to process data.

This course is a little less technical than some of our other database-related content, so if you don't have Python or SQL skills, that's fine. This course is really ideal for those who want to learn a little bit more about how all of the pieces go together to understand more of where to dive in deeper.

If you have any feedback relating to this course, please let us know at

Learning Objectives

  • Learn how to put together a data processing solution for an insurance company
  • Plan the project
  • Build the front-end interface, the back-end database, and the middleware that connects the two
  • Put the whole dashboard solution together

Intended Audience

  • Data engineers and database administrators
  • Anyone who wants to gain insights into how a data-handling solution is built in a real-world environment.


To get the most out of this course, you should have some basic experience with databases and building IT solutions.


Okay, so now we've talked about the back end. We've talked about the front end, and now it's time to talk about the glue that connects these two things, which is the middleware. So when a front-end user makes a request to view a particular table or visualization on our BI dashboard, the middleware will parse that request and then return the data needed for the database. So a good technology for the middleware layer is a REST API.  REST, which stands for representational state transfer, is a common architectural style used in creating Web services. 

An API or application programming interface acts as an abstraction layer. So this means that the front-end programmers, who are writing in HTML or JavaScript and designing the Web UI, don't need to understand the back-end database. They don't need to know the schema of our policy and our claims table. All they need to know is the URL for the API. And then they make a get request, which will return the data that they want in a specified format, usually a text format or a CSV or a JSON format. JSON is very common for APIs. And once the data has been returned in this expected format, it can be parsed and displayed in the front end, either as a table or used to build a visualization. 

REST APIs can be implemented in many different programming languages, including scripting languages such as PHP or Node JS or compiled languages like C Sharp, dot Net or even Go. Python, which is a scripting language, is a good choice because it's a very popular programming language. Lots of programmers know how to write in Python, having learned it for either writing APIs or other purposes, and Python has a library called flask, which allows users to build APIs fairly simply and easily. 

So now we can turn for one final time back to our Acme claims dashboard example. And now we've built the front end and the back end, and we're talking about how we're going to build the middleware and connect those two things. So you would call a meeting with your API developers in your technology division, and you would talk to them about how you were gonna build out this API, and let's say you decided to use Python and flask. Your developers say Great, we know how to use Python, that works great. They would actually look at the wireframes that were created by your UI team, which would give them an idea of exactly the data that was needed for each visualization on the dashboard, so each card that the dashboard has that you serve up, so a bar chart or a table.  Looking at the wireframes would tell your API designers what data they needed for that. And one way to do the API design is that for each card or visualization on your dashboard, you have a separate URL that calls out to the API and returns JSON data. So there's an example here, which has a Web URL that ends with slash API slash v one slash claims and that has a question mark type equals flood. And the slash claims is telling you that you want to pull claims data and then after the question mark, that's giving you an API get statement, what the query parameters are. So in this case, we're saying we only want to pull claims type of flood. So that's essentially a filter or a query parameter. And what this would do is it would pull all historical claims that are labeled as type flood in your database, and it would return it as a nice JSON object in an expected format, which then your front-end developers could parse exactly how they expected to be to display, let's say in a table so that your users could just filter through all of those claims for flood.


Introduction - Case Study Scenario - Planning - Building the Database - Front-End Design - Claims Dashboard: Putting it Together

About the Author
Learning Paths

Calculated Systems was founded by experts in Hadoop, Google Cloud and AWS. Calculated Systems enables code-free capture, mapping and transformation of data in the cloud based on Apache NiFi, an open source project originally developed within the NSA. Calculated Systems accelerates time to market for new innovations while maintaining data integrity.  With cloud automation tools, deep industry expertise, and experience productionalizing workloads development cycles are cut down to a fraction of their normal time. The ability to quickly develop large scale data ingestion and processing  decreases the risk companies face in long development cycles. Calculated Systems is one of the industry leaders in Big Data transformation and education of these complex technologies.