DEV Community: Nathan Rajkumar

Building a Scalable Microservices Application with Java Spring Boot and Angular

Nathan Rajkumar — Wed, 30 Oct 2024 18:08:25 +0000

PART 2: Playing With Lego

Make sure to check out Part 1 if your following along in our little adventure otherwise, tally ho!

Okay, day one of the first day of sprint 1, and we are sitting in the boardroom with a whiteboard and a laptop. Where and how do we start?

We need to keep in mind a few guiding principles when designing a new system to ensure that we follow design patterns and best practices.

Why? Each choice can make or break future decisions/processes in regards to maintainability, scalability, and fault tolerance. Plus, these are tried. tested and true software design concepts, so you know, there's that

The Big Question

Will this cost money to build? Locally no, we will be using as many free tier options as we can. However, I should mention that if we want to make this application scalable for more traffic, then yeah, there will be costs involved. Leverage at your own discretion.

Okay, lets start putting it together…

Our first component should be our front end…

Angular front end: Provides the user interface for shipping order creation, assignment, and notifications. Also, sends requests to the API Gateway.

Which then routes to our API Gateway…

API Gateway (Zuul): Manages routing, authentication and load balancing. This uses our service discovery to dynamically locate our backend services.

The new order shipping system, according to the CEO, should create orders, assign responsibilities to said orders to authorized users, and receive notifications on any status updates in real time. In other words…

Order Service: Manages orders, including creation and assignment, and publishes OrderCreated events to Kafka.

User Service: Manages authentication, authorization, and user profiles.

Notification Service: Listens to Kafka topics like order-created to trigger notifications.

All of these services registers itself with our Service Discovery so other services can discover and connect to it without hardcoded endpoints. Why? In the case a service cannot be reached at a URL or if the URL is changed at all for that service, it is a pain to have to manually change the URL especially in a large application. This can ultimately lead to scalability issues and cause headaches. So, we let our Service Discovery handle our service endpoints dynamically so we never run into the game of “what's the URL again?”

We also need to add some services to help with our microservice architecture…

Service Discovery (Eureka): Central directory (think like a phone book) where each microservice registers itself upon startup. It also periodically checks service health which then de-registers any failed instances to prevent sending requests to down services. Popular choices include Eureka, Consul, and Spring Cloud Service Registry. We are using Eureka for this build. Why? Eureka is integrated into Spring Cloud, provides self registration, health monitoring and easy API based lookup.
Kafka Broker: Manages topics for event-driven communication among microservices. What are Kafka topics? Kafka topics support asynchronous, event-driven interactions that reduce direct dependencies between services. What this means is that its a non blocking way to send data back and forth without waiting on any synchronous processes. Also, its event driven, which means its listening, queuing up its own messages within a “topic”, then releasing them every time the listening event is triggered.

Centralized Logging and Monitoring (ELK Stack and Prometheus): We are using the ELK (Elasticsearch, LogStash and Kibana) stack to consolidate all the logs from our services for easier debugging and troubleshooting. For monitoring, Prometheus by Grafana allows us to track real time system metrics where we can ensure our application stays performant and most importantly, available.

So far, it should look like this…

lucid.app

Breakdown

Lets take a look at some core principles and patterns:

Single Responsibility Principle (SRP)

Each microservice in this system has a focused responsibility:

Order Service is only concerned with managing orders
Notification Service exclusively handles notifications
User Service is responsible for managing user data

Why? Here we want to make sure we separate our concerns. Why would we want to do this? We want to reduce interdependencies, ensuring that changes in one service have minimal impact on others. SRP aligns with modularity which simplifies testing and allows each service to scale independently if needed

Database per Service Pattern

Every service in this architecture has its own database:

The User Service uses a MySQL relational database to store structured user information
The Order Service leverages a NoSQL MongoDB database like for fast, flexible storage of order data
The Notification Service uses our message queue system in our published topics to send and receive notifications when triggered.

Why? This pattern provides data isolation which means we can enhance data resilience by eliminating shared database dependencies between services. Each service can choose the database type that best fits its needs, which is particularly helpful when thinking about scaling our application

Event-Driven Architecture

An event-driven approach enables asynchronous communication between services. For example:

When a new order is created, the Order Service publishes a OrderCreated event to a Kafka topic.
The Notification Service listens to this topic and responds by sending notifications to users

Why? The whole point of microservices is keyed into the decoupling of services where we allow each component to work independently. With Kafka, we gain a high-throughput, scalable messaging platform that ensures data consistency while allowing non-blocking communication between services

Saga Pattern for Distributed Transactions

The Saga pattern manages distributed transactions by breaking them into smaller, compensable transactions. For instance:

When a new order is assigned, the Order Service first creates the order and publishes an OrderAssigned event
The Notification Service picks up this event and sends notifications to the relevant users
If the Notification Service encounters an error (e.g., a network issue), the Order Service can compensate by marking the task as “Incomplete” or retrying notifications

Why? This approach to handling distributed transactions with compensating actions keeps data consistent without locking resources, which is ideal for a distributed architecture. What does compensating action mean? If there is ever a moment when a service returns a failure, returns something undesirable or unexpected, the action will abort and previous actions are reverted.

API Gateway Pattern

The API Gateway acts as a single entry point for client requests, reducing the complexity of managing multiple endpoints.

Centralized Authentication: Authentication checks happen at the gateway level, so each service doesn’t need to implement its own.
Routing and Load Balancing: Requests for orders, users, or notifications are routed to the correct microservice, balancing load and providing a single unified entry point for clients

Why? The API Gateway not only simplifies the client’s experience but also provides a layer of control over security, traffic management, and monitoring

Circuit Breaker Pattern

For resilience, we will use the circuit breaker pattern to handle failures in dependencies. For example, if the Notification Service is down:

The Order Service can use a circuit breaker to prevent further calls to the Notification Service until it is back up
This isolates the failure to the Notification Service, preventing a ripple effect across other services

Why? Using tools like Resilience4J, we can implement circuit breakers to handle dependency failures gracefully and prevent cascading issues across the system

Centralized Logging and Monitoring

To maintain visibility into each service’s health, we use:

ELK Stack (Elasticsearch, Logstash, and Kibana) for centralized logging
Prometheus for real-time monitoring and alerting

Why? For monitoring we need a way to centralize logging so developers and operations teams can identify and resolve issues proactively by viewing logs, system metrics, and real-time data on service behavior

Lets Put It All into Perspective

Let’s consider a typical scenario, like creating a new order. Here’s how the architecture and design patterns work together:

Client Request: A user creates an order through the frontend, which hits the API Gateway

Gateway and Order Service: The API Gateway authenticates the user and routes the request to the Order Service

Event Publication: The Order Service stores the order in its database and publishes an OrderCreated event to Kafka

Notification Service: The Notification Service listens for OrderCreated, sends notifications, and publishes a NotificationSent event

Error Handling: If the Notification Service fails, a Saga compensating action triggers the Order Service to handle the failure by either retrying or marking the order as incomplete

Okay, day one completed, tomorrow we can start looking at the backend infrastructure and exploring and setting up event driven communication using Kafka.

Building a Scalable Microservices Application with Java Spring Boot and Angular

Nathan Rajkumar — Tue, 29 Oct 2024 16:23:05 +0000

PART 1 - The First Consultation

Look, while I enjoy microservices as much as the next guy, do I think that they are a huge headache to deal with and debug? Yes. But, the microservice architecture is such a hot button topic amongst devs and recruiters that I'd be amiss to not sandbox my own massive scalable project that's production ready while also keeping costs low or non existent cause hey, we're all broke.

The Scenario:

Congratulations! You were hired at IceToMeetYou Inc. as a consultant and they are looking to upgrade their current shipping management software to a more custom solution. IceToMeetYou Inc. is a startup who just got about $3B dollars in funding for their product that sells imported ice cubes to one guy stuck in the desert. Their current task management software is too small and limited in its functionality to handle all the incoming shipments this one guy, lets call him Dennis, needs to keep his smoothie cold. They want to build some task management system that can handle multiple incoming orders from Dennis to completion, assign orders to their worker penguins delivering the ice, track the progress of said penguins and receive real time notifications of status updates. With this, the CEO says to please feel free to ask any questions that can help build this project. We are going to be doing just that as we start to think about the project build…

Tech Stack:

For this project, we will use the following tech stack:

Backend: Java Spring Boot due to it being a powerful framework for building REST APIs and microservices, offering a wide array of tools like service discovery, cloud deployments, and Kafka for event-driven systems.
Frontend: Angular due to its robust front-end framework with NgRx for global state management
Database: MySQL/PostgreSQL (for relational data), MongoDB (for task data)
Real-time updates: Kafka (for event streaming) and WebSockets
Deployment: Docker and Kubernetes for orchestration
Testing: JUnit, Jest, and K6 (for load and performance testing)

The Big Picture:

The main purpose here is to demonstrate all the movable parts when thinking about a web application. While in no part is this list exhaustive, the goal is to cover a lot of bases in plain English so that this process is repeatable and a no brainer when thinking about enterprise applications. For each section, I will showcase each step from design to deployment to pass for a V1 MVP via deep dive blogs, code demonstrations, diagrams, thought processes and most importantly, always making sure we are solving the problem.

Microservice Architecture:

→ Design Principles: Understanding and implementing microservices principles such as service independence, scalability, and fault tolerance
→ Service Isolation: How to separate into its own areas of concern,
→ Inter-Service Communication: Choosing communication strategies (REST APIs, Kafka, WebSockets) and handling data consistency across services.

Backend Development With Spring Boot:

→ Service Development: Implementing individual services using Spring Boot, handling RESTful endpoints, and ensuring proper isolation of concerns.
→ Authentication & Security: Using JWTs, OAuth, and Spring Security for secure user authentication and role-based access control.
→ Database Management: Setting up relational (MySQL/PostgreSQL) and NoSQL (MongoDB) databases, optimizing data storage for microservices, and handling data migrations.

Frontend Development With Angular:

→ User Interface Design: Creating a seamless user experience using Angular
→ State Management: Handling application state with NgRx for consistent, reactive user interactions.
→ API Integration: Connecting the Angular front end to Spring Boot backend services via RESTful APIs and managing data transfer securely.

Real Time Data Communication and Notifications:

→ Websockets & Event Streaming: Implementing WebSockets for instant updates and Kafka for reliable event streaming between services.
→ Push Notifications: Delivering real-time updates to users, ensuring efficient message distribution without overloading services.

Performance Testing & Monitoring:

→ Load Testing: Using K6 to assess the system under load, identifying bottlenecks, and optimizing microservices for performance.
→ Logging & Monitoring: Implementing logging with ELK or alternative tools, tracking application health, and setting up alerts for critical failures.

Deployment & Scaling:

→ Containerization With Docker: Building Docker images for each service, establishing a consistent runtime environment for easier scaling.
→ Orchestration With Kubernetes: Using Kubernetes to manage deployments, auto-scaling, load balancing, and resilience.
→ Cloud Hosting: Hosting services on cloud platforms (AWS, Azure, GCP), covering aspects like cost efficiency, security, and reliability.

Some Final Thoughts Before Show Time...

For starters, its a sandbox so this project is built for learning and demonstration. Big note here: This is a 100% over engineered solution built from scratch by one guy sitting in a basement. It's not that serious.

I will be updating and working on this project everyday so expect frequent updates!

This is also an exercise in what development would be like within a team setting, so we will be working within "sprints" to hit our goals with retrospectives (with, I guess, myself?) to see what went right, what went wrong, what blockers did we come across and how can we solve them. I will update doing a quick retro every 5 posts or so.

ONE MORE THING…I am always ALWAYS hungry for feedback. If something doesn't make sense or is not clear enough, let me know in the comments.

So, its getting late, Sprint 1 starts tomorrow, hold on to your hats, its going be a long day…