RAP: Let’s discuss the architecture and technical details

Reading Time: 4 minutes

In the previous blog, we discussed the journey and the features of RAP. In this blog, we will discuss the architecture and technical details.

RAP Architecture:

We have tried to follow the Domain-Driven Design and Reactive principles in designing RAP architecture. All RAP team members completed all the Reactive Architecture courses launched by Lightbend on cognitive classes to ensure adherence to reactive principles. These courses helped us to design the architecture in a better way and helped us to refactor the code as per the design principles learned in the courses. We designed the backend system as four micro-services:

  • User service
  • Asset Service
  • Booking Service
  • Notification Service

User Service: This service is responsible to handle the user-related operations.

Asset Service: This service is responsible to handle all the asset-related operations.

Booking Service: This service is responsible to handle all booking related operations.

Notification Service: This service is responsible to send out the notification to the users.

These services interact with each other through REST APIs only. The first three services have their separate databases. No service can interact with other databases directly. For ex: If Asset service wants to access user data then it needs to call User service using REST endpoint.


In the above diagram, you can see the flow of the system. Let’s discuss it in detail:

  • Notification service does not call any other service. We have used Akka actor in this service to send out notifications to a user. Currently, we are using Email notification only. It has a rest endpoint which internally bangs a message to an actor to send the notification. User and Booking service calls the Notification service endpoint with all the required payload to send out the emails.
  • User service only calls Notification service. All other services like Asset and Booking call User service for the user details and the authorization part.
  • Asset service calls only User service for the authorization part only.
  • Booking service is the only service who calls all other services. It calls User service for the authorization and user details, Assets service to get the Asset details and Notification service to send out the notifications.
  • UI client can call User, Asset and Booking service directly but can not call Notification service.

So this is all about the flow of the system. Now let’s discuss the technologies used in the RAP.

Technology Stack:

First, we will discuss the backend technologies.


We started with the following technology stack:

  • Lagom: Microservice framework with ES and CQRS
  • Cassandra: NoSQL database
  • Kafka: For messaging system
  • Scala: Programming Language
  • SBT: Build tool

We started with Cassandra as a NoSQL database and Kafka as a messaging system but later we realized that Cassandra is not suitable as per our requirements and Kafka is not required.

Cassandra was not suitable for our queries. There were some queries which were not supported by the Cassandra. Also, Cassandra data modeling was becoming a blocker for us. So we decided to shift towards MySQL. We were using Event Sourcing and CQRS with Cassandra and as Lagom supports the same for MySQL as well so it was easier to shift on MySQL for us.

Similarly,, Kafka was too heavy for us just to use it for sending the notifications asynchronously. Therefore, we decided to shift towards the Akka actor which is a much lighter toolkit to send out the notification in a non-blocking way.

So the final backend technology stack is:

  • Lagom: Microservice framework
  • MySQL: Relational Database
  • Akka Actor: For sending asynchronous messages
  • Scala: Programming Language
  • SBT: Build tool


  • Angular 7: UI Framework
  • Angular material: Designing library
  • HTML, CSS: UI technologies
  • NPM: Build tool
  • Karma: Unit test cases library

We at Knoldus, do focus on writing quality code. We believe that quality code is the key to success. It saves a lot of time and efforts in the long run, therefore, we do not compromise ever in code quality. To ensure the code quality, we use CodeSquad here for every project. CodeSquad provides us a qualitative analysis and insight into the projects by highlighting the missing or the problematic parameters.

Please see below the code quality analysis for the project:

Backend reports:



UI Portal Report:


So this is all about the technical details of RAP. Please review and let us know your feedback.


Written by 

Rishi is a tech enthusiast with having around 10 years of experience who loves to solve complex problems with pure quality. He is a functional programmer and loves to learn new trending technologies. His leadership skill is well prooven and has delivered multiple distributed applications with high scalability and availability by keeping the Reactive principles in mind. He is well versed with Scala, Akka, Akka HTTP, Akka Streams, Java8, Reactive principles, Microservice architecture, Async programming, functional programming, distributed systems, AWS, docker.