A.

Anny Leema Associate Professor Sr, Department of Analytics, SCOPE, VIT Vellore
What is a Monolithic Architecture?

 Software is traditionally designed using a monolithic

architecture, in which the entire program is
constructed as a single, indivisible unit.
 Every component of the program, including the data
access layer, business logic, and user interface, is
deployed and integrated tightly together in this
design.
 The image illustrates the concept of Monolithic Architecture, where
all software components of an application—such as the user
interface, business logic, and data access—are assembled together
into a single tightly coupled unit.
 When a user sends an HTTP request from the Client Side UI (e.g., a
browser), it is handled by the Server Side Application, which
executes the domain-specific logic, retrieves or updates data from
the database, and then populates the appropriate HTML views to
be sent back to the user's browser.
 This tightly integrated structure means all components are deployed
and scaled together, which can lead to challenges in flexibility,
scalability, and maintenance as the application grows.
Customer Service, Product Service,
Cart Service are all combined into
one big application — running in a
single instance (one server) or one
deployable unit

If we want to modify anything, rebuild

the entire application, not just one
part

Small change affect the other services

and we need to test the entire system
again.
 Monolithic Applications
 If all the functionalities of a project
is implemented in a single code ,
then that application is known as
monolithic application
◼ “mono” represents the single
codebase containing all the required
functionalities
 Advantages of monolithic
applications:
 Simple to develop relative to
microservices where skilled
developers are required in order to
identify and develop the
microservices.
 Easier to deploy as only a single
jar/war file is deployed.
 Relatively easier and simple to
develop in comparison to
microservices architecture.
 The problems of network latency
and security are relatively less in
comparison to microservices
architecture.
Scenario: A university's internal portal is built as one large
application — if the attendance module fails, the entire app
crashes.
Advantages:
 Simple to develop and test initially

 Easy deployment

Disadvantages:
 Difficult to scale and maintain

 Small changes require full redeployment

 Disadvantages of Monolithic applications:
 It becomes too large in size with time and hence, difficult to manage.
 Need to redeploy the whole application even for a small change.
 As the size of the application increases, its start-up and deployment time also
increases.
 For any new developer joining the project, it is very difficult to understand the
logic of large Monolithic application even if his responsibility is related to a
single functionality.
 Even if a single part of the application is facing a large load/traffic, we need
to deploy the instances of the whole application in multiple servers. It is very
inefficient and takes up more resources unnecessarily. Not supporting horizontal
scaling.
 It is very difficult to adopt any new technology which is well suited for a
particular functionality as it affects the whole application, both in terms of time
and cost.
 It is not very reliable as a single bug in any module can bring down the whole
monolithic application.
 It visually conveys the limitations
of this approach:
 Unreliable – If one part fails, the
whole system fails.
 Unscalable – You can't scale one
service (like just Cart Service);
you must scale everything
together.
 BlocksContinuous Development
– You can’t update just one part
without affecting the whole
application.
 Slow Development – Developers wait on
each other because everything is connected.

 Large & Complex Applications – Over

time, the app becomes a monster that’s hard
to maintain and understand.This image
explains—in a simple and visual way—why
monolithic or tightly coupled systems can fail
badly and cause user frustration

 Note:Imagine your house has only one switch

that controls all lights, fans, and the fridge.
If that switch breaks, everything goes dark.
 That’s how monolithic systems behave—one
problem brings down the whole system.
 What are web services?
A web service is any piece of software that makes itself available over the internet and
uses a standardized format—such as Extensible Markup Language (XML) or JavaScript
Object Notation (JSON)—for the request and the response of an application
programming interface (API) interaction. A web service is not for direct use by people,
but by other programs or applications. Ex: A weather API that gives temperature and
forecast to a mobile app.
A web service lets apps talk to each other over the internet to exchange data — like
weather info, payments, or messages.

12
 Service Oriented Architecture (SOA)
 SOA was created to solve problems in
monolithic applications.
 It breaks a big application into smaller
parts called services.
 These services talk to each other through a
central system called the Enterprise
Service Bus (ESB). It is like a central
manager or traffic controller. All
communication goes through the ESB.
 Limitations: Services often shared the
same database, which made them
dependent on each other.
 Too much control by ESB—if ESB fails,
everything can break.
 Services were not always truly
independent.
 Service Oriented Architecture (SOA) vs MicroServices
Architecture(MSA)
Microservices is a modern version or evolution of SOA (Service-Oriented
Architecture).It follows many ideas from SOA, but with more independence and less
dependency.
Concept SOA Microservices
SOA is a big service Microservices are tiny
Design
system (like a toolkit). independent tools.
Services talk through ESB Services talk directly to
Communication
(central manager). each other.
Services may share the Each service has its own
Database
same database. database.
Tightly connected (more Loosely connected (less
Dependency
dependencies). dependencies).
What is Microservices?

 Microservices is an architectural style that organizes an

application as a group of smaller services instead of a
single bulky service.
 They are the building blocks of an application using
the microservice architecture style.
 Loosely coupled
deployable independently as a single entity
Highly maintainable and testable
What is a Microservices Architecture?

 Microservice architecture is the design pattern or approach where

an application is structured as a collection of microservices.
 Each service does one specific job, can be developed and
deployed separately, and talks to other services using APIs.
 Each one represents a business capability in itself.
 The services loosely couple with one another and communicate over
the network, typically making use of lightweight protocols such as
HTTP or messaging queues.
 The Microservice architecture has a significant impact on the
relationship between the application and the database.
Scenario 1: Imagine an online shopping app with these services:
 User Service – handles logins and user accounts

 Product Service – manages product listings

 Order Service – processes customer orders

 Payment Service – handles payments

 Each of these runs separately, can be updated on its own, and can
even be built in different programming languages.
Key Characteristics:
 Loose coupling

 High cohesion(All the internal functions should be closely related.)

 Language-agnostic

 Scalable and fault-tolerant

Microservice What It Does Tech Stack Example

Java/Spring Boot +
Customer Service Login, register, profile
MySQL

Show products,
Product Service Node.js + MongoDB
manage inventory

Cart Service Add to cart, view cart Python + PostgreSQL

React/Angular
UI Service frontend for user React + REST APIs
interface
Fundamental aspects of microservices:
 Decentralized architecture: Microservices are designed to be
loosely coupled and independent of each other.
 Each service is responsible for its own business logic and data
storage, making it easier to scale and update components
individually.
 Lightweight communication: Microservices communicate with each
other using lightweight mechanisms such as RESTful APIs or message
brokers. This enables them to be more flexible and resilient than
traditional monolithic architectures.
 Independent deployment: Each microservice can be
deployed independently, which means that changes to one
service do not necessarily require updates to other services.
 This allows for more frequent updates and easier
deployment.
 Polyglot programming: Microservices can be written in
different programming languages, which allows developers
to use the language best suited for a particular task or
service.
Automated Management
 In a microservices-based app, there may be dozens or even
hundreds of small services.
 Manually managing all of them (starting, stopping, updating,
checking health) would be very hard.
 So, we use automation tools like Kubernetes, Docker, and CI/CD
pipelines to:
 Automatically deploy new versions

 Monitor services for health and performance

 Scale services up or down as needed

Resiliency
 Microservices are built to be strong and fault-tolerant. If one
service (e.g., the payment service) fails, the rest of the system
(like catalog or search) should keep working.
 Each service is isolated, which means:
 It can fail without crashing the whole app
 Backup systems or retry mechanisms can handle the error
Scalability
 Since each microservice is small and independent, you can

scale only what’s needed.

 Example:

 If thousands of users are checking out at once, you can scale

only the checkout service—not the entire app.

 This is called horizontal scaling—you add more copies
(instances) of that specific service.
Disadvantages of microservices:

 Instead of one big program, you have many small ones. Managing all these
services becomes difficult as the app grows.
 Skilled developers are required to work with microservices architecture which
can identify the microservices and manage their inter-communications.
 Independent deployment of microservices is complicated.
 Microservices are costly in terms of network usage as they need to interact with
each other and all these remote calls results into network latency.
 More communication between services means more chances for hackers to attack
if not secured properly.
 Debugging is difficult as the control flows over many microservices and to point
out why and where exactly the error occurred is a difficult task.
Microservices Design Patterns and Principles
1. Scalability
2. Flexibility
3. Independent and autonomous
4. Decentralized governance
5. Resiliency
6. Failure isolation
7. Continuous delivery through the DevOps
 Microservices design approach/principles
 High Cohesion Combined With Loose Coupling
◼ When breaking down a monolithic architecture into smaller services or components, it is
important to combine similar functionalities.
◼ This combination of related logic into a single unit is known cohesion.
◼ The higher the cohesion, the better is the microservice architecture.
◼ A low cohesion would indicate too much communication between different services leading to a poor
system performance.
 Unique Source Of Identification
◼ Each item (like Order, User, Product) has a unique ID.
◼ Systems rely on ID instead of full details.
◼ API Integration
◼ Microservices talk to each other using APIs.
◼ They don’t share code — they just send/receive data.
◼ Data Storage Segregation
◼ Any data stored for a specific service should be made private to that specific service and can
be shared with any other service only through an API
 Traffic Management
◼ Traffic to different services will vary and a service may run slowly or may be flooded with calls.
 Microservices design approach/principles
 Automating The Process
◼ Microservices designed independently should be able to function in its
own accord.
◼ The automation would enable self-deployment and function without the
need for any intervention.
 Minimal Database Tables
◼ To ensure that the microservice is focused towards business function, a
microservice design should have only a couple of tables even with data
entries running into millions.
 Constant Monitoring
◼ establish a process for actively monitoring the storage of the data in a
central location
◼ frequent changes without affecting the performance of the system
 While adhering to the principles there are some
standard sets of problems & complex scenarios that
architects and developers need to address.
 To solve these problems, they use design patterns
— reusable templates or best practices.
 Patterns are predefined solutions, act like
blueprints that save time and help avoid mistakes.
 Microservices is not just about breaking an app into
small pieces.
 It involves many design decisions: deployment,
communication, data, security, UI, testing, etc.
 This diagram gives a complete view of all the key
parts of microservice architecture.
Three building blocks of microservice
architecture.
1. Application Patterns
 What it is: How to design and organize microservices.

 Break a big app into small services (like Orders,

Payments).
 Each service can have its own database.

 Use smart techniques (like Saga, Events) to keep

services in sync.
Application Patterns
 Decomposition:
 Decompose by Business Capability: Break the system into services aligned with business areas (e.g., billing, shipping).
 Decompose by Subdomain: Divide based on domain-driven design concepts like core, supporting, and generic subdomains.
 Self-contained Service: Each service manages its own UI, logic, and database.
 Service per Team: Assign each service to a small, cross-functional team.
 Data
 Database Architecture:
◼ Shared Database: Multiple services access the same database (not recommended for microservices).
◼ Database per Service: Each service has its own private database to ensure loose coupling.
 Querying/Data Patterns:
◼ API Composition: A composite service aggregates data from multiple microservices.
◼ CQRS (Command Query Responsibility Segregation): Separate data modification (command) and data reading (query) logic.
 Maintaining Data Consistency:
◼ Aggregate: A cluster of domain objects treated as a single unit for data changes.
◼ Saga: A sequence of local transactions to maintain consistency across services.
◼ Domain Event: Services communicate by publishing events about what just happened.
◼ Event Sourcing: Store changes as a sequence of events instead of current state.
 UI & Testing:
 Consumer-Driven Contract Test: Define expectations of consumers to test provider services.
 Consumer-Side Contract Test: Verify client expectations against the service.
 Service Component Test: Test individual services in isolation.
 Server-Side Page Fragment Composition: Build UI on the server using fragments from various services.
 Client-Side UI Composition: UI is assembled on the client side from different microservices.
2. Application Infrastructure Patterns
 What it is: How services talk, stay secure, and handle
errors.
 Services talk using HTTP (sync) or messaging queues
(async).
 Add security, logging, and health checks.

 Handle failures using Circuit Breakers and Retry logic.

Application
Cross-Cutting Concerns:
Infrastructure Patterns
 Service Template: Blueprint to generate consistent microservices.
 Microservice Chassis: Frameworks or libraries that include standard features like logging or metrics.
 Externalized Configuration: Store service configuration outside the application code (e.g., in environment variables
or config servers).
 Security:
 Access Token: A digital token used to authenticate and authorize access to services.
 Communication Style:
 Remote Procedure Invocation: Call a function/service on another system like it's local.
 Messaging: Use asynchronous messages for communication between services.
 Domain-Specific: APIs are designed around business domains.
 Reliability:
 Circuit Breaker: Stops calls to a failed service to avoid cascading failures.
 Messaging:
 Idempotent Consumer: Ensures that duplicate messages are handled safely without side effects.
 Transactional Messaging:
 Transactional Outbox: Store outgoing messages in the same transaction as database changes.
 Transaction Log Tailing: Listen to database changes through logs and convert them into messages.
 Polling Publisher: Periodically check the outbox table and send messages.
3. Infrastructure Patterns
 What it is: Where and how to run services.

 Run each service in its own container or VM.

 Use tools to help services find each other (Service

Discovery).
 Use API Gateways to connect outside users.
Infrastructure Patterns
 Deployment:
 Multiple Services per Host: Deploy many services on one machine (not scalable).
 Single Service per Host: Deploy one service per host for isolation and simplicity.
 Service-per-Container: Use containers (like Docker) to run each service independently.
 Service-per-VM: Run each service on a dedicated virtual machine.
 Sidecar: Deploy support functionality like logging or monitoring alongside the main service.
 Service Mesh: A layer to handle service-to-service communication, security, and observability.
 Serverless Deployment: Deploy functions that run on demand without managing servers.
 Service Deployment Platform: Tools to automate deployment, scaling, and updates (e.g., Kubernetes).
 Discovery:
 Service Registry: A directory of all available services and their locations.
 Client-Side Discovery: Client queries service registry to find the service.
 Server-Side Discovery: A proxy or load balancer finds the service on behalf of the client.
 Self Registration: Services register themselves with the registry when they start.
 3rd Party Registration: An external service registers instances with the registry.
1. Service Decomposition Patterns
2. Service Integration Patterns
3. Communication Patterns
4. Database and Transaction Patterns
5. Reliability and Resilience Patterns
6. Security Patterns
7. Observability and DevOps Patterns
 Problem Faced in Microservices Solution (Pattern) Example in E-Commerce (ShopEZ)
Order Service asks: “Where’s the Inventory
Services need to talk to each other
Service Discovery Pattern Service?” — Uses a registry (like Eureka)
efficiently
to find it.
If Payment Service is down, Circuit Breaker
Too many requests may crash a weak
Circuit Breaker Pattern stops retrying and shows a fallback: “Try
service
again later.”
One API Gateway routes: /products →
Users must access multiple services API Gateway Pattern
Product Service, /orders → Order Service.
User Service uses MySQL, Catalog Service
Each service needs its own database Database per Service Pattern uses MongoDB. They manage data
separately.
First migrate Product Search into a
Slowly replacing a big old system with
Strangler Pattern microservice. Then migrate Payments,
microservices
Orders, etc.
Placing an order updates inventory,
Need to update multiple services in one go Saga Pattern (for long transactions) payment, shipping — all done step-by-
step with rollback support.
When an order is placed, Order Service
Sending real-time updates between
Event-Driven Pattern sends an event → Inventory Service
services
updates stock automatically.
Adding features like logging, security per Cart Service has a helper container that
Sidecar Pattern
service logs every update, runs security checks.
 Circuit Breaker Pattern
 The Circuit Breaker Pattern is used in Microservices to protect your system from failure and
overload.
 It is a technique used in Microservices architecture to improve the resilience and reliability of
distributed systems.
 Circuit Breaker Pattern in software protects your app from crashing when another service is slow
or failing.
 The basic idea behind the circuit breaker is very simple. You wrap a function call in
a circuit breaker object, which monitors it for failures.
 Once the failures reach a certain threshold, the circuit breaker trips and all further
calls to the circuit breaker return an error, with any further calls skipped.
 The Circuit Breaker can also be configured to handle failures in different ways, such
as returning a default value or a cached response.
Function Explanation
If a service is failing, the circuit breaker blocks further
Stops repeated failed calls
calls to avoid wasting time and resources.
It monitors the number of failures (like timeouts, errors) in
Detects failures
service calls.
It waits for a while before trying the failed service again
Waits before retrying
(to see if it’s back).
It prevents one failing service from affecting the whole
Improves system stability
system.
It can return a default value, error message, or cached
Returns fallback responses
data instead of crashing.
Here are the basic steps involved in the Circuit Breaker Pattern:

 Identify the Microservices that need to communicate with each other

 Add a Circuit Breaker between the Microservices
 Add configurations to monitor the status of the Microservices and
detect failures
 If a Microservice fails to respond, the Circuit Breaker can prevent
further requests to the Microservice and handle the failure in an
appropriate way
 In some cases, the default response is also configured, which will
help to handle failures gracefully.
Cloud Native Application
Cloud Native Applications
 Cloud native applications are a new way of building and deploying
software that take full advantage of the cloud computing model.
 A Cloud-Native Application is an application designed to run in the
cloud environment from the very beginning. It's built using modern tools
and practices so that it:
 Automatically scales based on demand
 Recovers from failures quickly
 Can be updated easily without downtime
Characteristics of a cloud-native Application

1. Microservices-based: Microservices divide an app into a set of self-

contained services, or modules. Each service makes reference to its
data and fulfils a certain commercial objective. These modules can
communicate with one another through application program interfaces
(APIs).
2. Container-based: Cloud native applications are typically built using
containers, which are lightweight, portable, and self-contained units of
software that can be easily deployed and run on any infrastructure.
This allows for greater flexibility and ease of deployment, as well as
increased security and isolation.
Characteristics of a cloud-native Application

 Automation: Cloud native applications are typically deployed and

managed using automation tools, such as Kubernetes and Ansible, which
allow for easy scaling, monitoring, and management of the application. Ex:
In an e-commerce site, if one product service crashes, Kubernetes restarts it
instantly without disturbing users. The rest of the app (login, cart, etc.) keeps
working.
 Continuous integration and delivery: Cloud native applications are
typically built and deployed using a continuous integration and delivery
(CI/CD) pipeline, which allows for faster and more frequent releases.
 Resilience: Cloud native applications are designed to be resilient to
failures, and are typically built with redundancy and self-healing
capabilities.
Microservice What It Does Why It’s Self-Contained
Handles user registration Has its own user
User Service
& login database and APIs
Stores product info
Product Service Manages product details
separately
Manages placing and Owns its own order DB,
Order Service
tracking orders handles payment API
Independent queue or
Notification Service Sends emails/SMS alerts
service
Advantages of cloud native app

 Reduced costs: Cloud native applications are designed to take full

advantage of the cloud computing model, which allows for more efficient
use of resources and lower costs.
 Increased scalability: Cloud native applications are highly scalable, which
means they can easily handle increases in traffic and demand.
 Increased availability: Cloud native applications are highly available, which
means they can continue to function even in the event of failures.
 Increased agility: Cloud native applications are designed to be flexible
and adaptable, which allows for faster development and deployment.
Example
 A simple example of a cloud native application would be a web-based e-commerce platform,
such as an online store for selling clothing.

 The application would be containerized, meaning that it would be packaged as a set of

containers, each with a specific function such as the web front-end, the database, and the
payment service.
 The application would use a microservices architecture, meaning that each component of the
application would be a separate service that communicates with other services through APIs.
 The application would use automation tools, such as Kubernetes, to deploy and manage the
containers in the cloud.
 The application would use a continuous integration and delivery (CI/CD) pipeline, which would
allow for faster and more frequent releases.
 The application would be designed to be resilient to failures, with features such as load
balancing, auto-scaling and self-healing capabilities.
 Difference between traditional and Cloud Native Application
Aspect Traditional Applications Cloud Native Applications
Automated using tools like
Deployment Manual setup on servers
Kubernetes, CI/CD
Tied to specific OS (e.g., OS-independent through
OS Dependency
Windows/Linux) containers (like Docker)
Hard to scale, needs manual Easily scales up/down
Scalability
effort automatically
Updates without downtime
Updates Downtime during updates
(rolling updates)
Right-sized (only what’s needed,
Resource Usage Over-provisioned (just in case)
when needed)
Built to handle failures gracefully
Resilience App may crash if server fails
(self-healing)
Fixed server costs, even if not Pay-as-you-go (optimized usage
Cost Efficiency
used fully and cost)
Faster due to automation and
Speed to Market Slower due to manual processes
Reference architecture for cloud-native enterprise systems
 Reference architecture for cloud-native enterprise
systems
 microservices,serverless functions, integration services, and
managed APIs are ready to be deployed on containers
handling production workloads
◼ Those components can be deployed on private, public, and hybrid
cloud environments using a cloud-agnostic container orchestrator
Factor Explanation
1 - Code Base A single code base for each microservice, stored in its own repository. Tracked with version control, it can deploy to multiple
environments (QA, Staging, Production).
2 - Dependencies Each microservice isolates and packages its own dependencies, embracing changes without impacting the entire system.
3 - Configurations Configuration information is moved out of the microservice and externalized through a configuration management tool outside
of the code. The same deployment can propagate across environments with the correct configuration applied.
4 - Backing Services Ancillary resources (data stores, caches, message brokers) should be exposed via an addressable URL. Doing so decouples the
resource from the application, enabling it to be interchangeable.
5 - Build, Release, Each release must enforce a strict separation across the build, release, and run stages. Each should be tagged with a unique ID
Run and support the ability to roll back. Modern CI/CD systems help fulfill this principle.
6 - Processes Each microservice should execute in its own process, isolated from other running services. Externalize required state to a backing
service such as a distributed cache or data store.
7 - Port Binding Each microservice should be self-contained with its interfaces and functionality exposed on its own port. Doing so provides
isolation from other microservices.
8 - Concurrency Services scale out across a large number of small identical processes (copies) as opposed to scaling-up a single large instance
on the most powerful machine available.
9 - Disposability Service instances should be disposable, favoring fast startups to increase scalability opportunities and graceful shutdowns to
leave the system in a correct state. Docker containers along with an orchestrator inherently satisfy this requirement.
10 - Dev/Prod Parity Keep environments across the application lifecycle as similar as possible, avoiding costly shortcuts. Here, the adoption of
containers can greatly contribute by promoting the same execution environment.
11 - Logging Treat logs generated by microservices as event streams. Process them with an event aggregator and propagate the data to
data-mining/log management tools like Azure Monitor or Splunk and eventually long-term archival.
12 - Admin Processes Run administrative/management tasks as one-off processes. Tasks can include data cleanup and pulling analytics for a report.
Additional Factors
New Factor Explanation
13 - API First Make everything a service. Assume your code will be
consumed by a front-end client, gateway, or another
service.
14 - Telemetry On a workstation, you have deep visibility into your
application and its behavior. In the cloud, you don't.
Make sure your design includes the collection of
monitoring, domain-specific, and health/system data.

15 - Implement identity from the start. Consider RBAC (role-

Authentication/ based access control) features available in public
Authorization clouds.
API fundamentals and Management
 Application Programming Interface (API)
 Basically a set of definitions and protocols that enable two applications
to talk to one another.
 The connectors that enable most of the communications between the web
applications, or apps, that we use today
 Enables communication with, and exchanging data between, other
systems
◼ Example Scenario
◼ use apps on your phone to check the weather,
◼ send a message to friends,
◼ to find the nearest café
 Benefits
◼ Speed-up the application development
◼ Secure exposing of record and business logic
◼ Socialize your APIs into developer and partner ecosystem
◼ Monetize enables new business channels by charging money for usage
 REST
1. REST (Representational State Transfer)
Microservices communicate using REST APIs, which are a standard way of sending and receiving
data over the web using HTTP.
Example
You have a User microservice. The frontend sends a request: GET /users/123. The
microservice replies with user data in JSON format.
2. Small Well-Chosen Deployable Units
Each microservice should be a small, focused piece of the overall application. It can be
developed, tested, deployed, and scaled independently. Example:
Example
OrderService only handles orders. Payment Service only handles payments If you fix or
update PaymentService, it won’t affect OrderService.

3.Dynamic Scaling
You can scale (increase or decrease) the number of instances of a microservice independently,
based on demand.
 This is a Microservices-based Architecture with the following key
parts:
 Clients: Web, Mobile, and PC
 API Gateway: Single entry point for all requests
 Identity Provider: Manages authentication & authorization
 Service Registry & Discovery: Keeps track of microservice locations
 Microservices: Modular business logic units (Shopping, Billing, User
Profile, Push Notifications)
 Databases: Each microservice has its own DB
 In a microservices architecture, the API Gateway acts as a single entry point that receives all incoming
client requests (from web, mobile, or PC) and intelligently routes them to the appropriate microservices
such as billing, shopping cart, or user profile.
 The API Gateway relies on an Identity Provider (IdP) such as Google, Keycloak, or Auth0 to manage
authentication (verifying who the user is) and authorization (what the user is allowed to do).
 Authentication & Authorization (Login Check)
 It checks:
 Authentication = Is the user real?
 Authorization = What is the user allowed to do?
 IdPa token (like a digital ID card), which the gateway checks before sending the request to the
correct service.
 Each microservice does one job , they are independent, so each can run, scale, or fail without
affecting the others.
Service Registry & Discovery-Keeps track of where all services are located. When the API
Gateway or another service needs to talk to a microservice, it asks this registry:“Where is the
Billing service running right now?”
Monitoring -Keeps track of how services are performing:Are they up or down?, Are they slow?.Is
there an error?
 Three main types of APIs
 Open APIs
◼ Publicly available with minimal restrictions to access them.
 Partner APIs
◼ Need specific access rights to be able to use them and are typically
exposed via an API developer portal.
 Internal APIs
◼ Hidden from external users and only exposed by internal systems.
 Two different ways that APIs can be implemented
 Simple APIs which are available separately.
 Composite APIs, where multiple data or service APIs are
combined together, allowing developers to access several APIs at
a time
 Three main types of API protocols
 REST(REpresentational State Transfer ) APIs
◼ Provides a uniform interface, where a client and server communicate with
one another via HTTP using URIs, the common Create, Read, Update, and
Delete (CRUD) operations, and most often JavaScript Object Notation
(JSON) conventions for data exchange
 SOAP APIs
◼ Simple Object Access Protocol is another type of heavy weight services
API.
 RPCs
◼ Request-response protocol, where a client sends a request to a remote
server to execute a specific procedure, and then the client receives a
response back. However, RPC APIs are much more difficult to maintain
and update than REST APIs,
 API development Styles
 REST, OpenAPI, HTTP, gRPC, GraphQL, and Kafka
 Tunnel (used in gRPC)
◼ The API is a collection of functions that can be called remotely
◼ The tunnel style is focused on making specific computer functions available
 Resources (used in OpenAPI)
◼ API is a collection of resources that can be interacted with
◼ HTTP that calls an API that’s been written following the OpenAPI specification
 Hypermedia
◼ the API is a collection of interlinked resources
◼ HTTP calls to an OpenAPI-described service, with the difference being that the data also includes
controls to link the resources together
 Query (GraphQL)
◼ API exposes a structured data model that can be queried and updated by using a generic query
language
◼ API needs to query the large dataset and return just the data needed for that query
 Event
◼ the communication pattern is reversed, and the API listens for events instead of asking for
information
Introduction to Java Micro Services
Java Micro services
 In a Java-based microservices architecture, the interaction between Spring,
Spring Boot, Spring Cloud, Maven, and REST can be understood in layers,
each playing a specific role in the development, deployment, and
execution of microservices.
 Spring Framework (Foundation)
 What: A comprehensive framework that provides core features like Dependency
Injection, AOP, and MVC.
 Role: Acts as the base layer. It manages bean life cycles, configurations, and
integrates components.
 In Microservices: Handles core functionalities like creating REST controllers, data
access, and validation
 Annotations: @Component, @Autowired
Java Micro services
 Spring Boot (Auto-config & Easy Setup)
 What: Built on top of Spring, it simplifies project setup using auto-
configuration, embedded servers, and minimal XML
configuration.
 Role:
◼ Starts embedded servers like Tomcat using main() method.
◼ Reduces boilerplate code.
◼ Manages project dependencies via spring-boot-starter-* modules.
 In Microservices: Each microservice is typically a standalone Spring
Boot application.
 Annotations: @SpringBootApplication
Java Micro services
 Spring Cloud (Distributed System Features)
 What: Provides tools to manage distributed systems (like microservices) using
Spring Boot.
 Features:
◼ Service Discovery with Eureka/Consul
◼ Load Balancing with Ribbon or Spring Cloud LoadBalancer
◼ Circuit Breaker with Resilience4j
◼ API Gateway with Spring Cloud Gateway
◼ Centralized Config with Spring Cloud Config
 In Microservices: Helps microservices register, discover each other, and
communicate resiliently
 Annotations: @EnableDiscoveryClient
Java Micro services
 Spring Cloud (Distributed System Features)
 What: Provides tools to manage distributed systems (like microservices) using
Spring Boot.
 Features:
◼ Service Discovery with Eureka/Consul
◼ Load Balancing with Ribbon or Spring Cloud LoadBalancer
◼ Circuit Breaker with Resilience4j
◼ API Gateway with Spring Cloud Gateway
◼ Centralized Config with Spring Cloud Config
 In Microservices: Helps microservices register, discover each other, and
communicate resiliently
 Annotations: @EnableDiscoveryClient
Java Micro services
 Maven (Build Tool & Dependency Manager)
 What: A build automation tool that manages project structure,
builds, and dependencies.
 Role: Defines the project via pom.xml Pulls libraries like Spring
Boot, Spring Cloud, and REST APIs from repositories.
 In Microservices: Each service has its own pom.xml and
manages its dependencies independently.
 Feature: pom.xml, <dependencies>
Java Micro services
 REST (Communication Protocol)
 What: An architectural style using HTTP methods (GET, POST,
PUT, DELETE) for communication.
 Role: Defines how microservices talk to each other.
◼ Implemented using @RestController in Spring Boot with
@GetMapping, @PostMapping, etc.
 In Microservices: Exposes APIs for CRUD operations between
services or with frontend apps.
 Annotations: @RestController, @GetMapping
Interaction Flow (Example)
1. Let’s say you are building a Product Microservice:
2. Maven (pom.xml) pulls:
1. spring-boot-starter-web (for REST)
2. spring-cloud-starter-netflix-eureka-client (for service registry)
3. You define a @RestController to expose REST APIs (/products, /products/{id}).
4. You run the app using Spring Boot’s main() class → it launches an embedded
Tomcat server.
5. The microservice registers with Eureka (Spring Cloud) and becomes discoverable.
6. Another microservice (e.g., Order) calls the Product service via REST using the
registered name.
Different ways to implement Microservices
Approach Language Best For Pros Cons

Powerful, integrated
Spring Boot + Spring Cloud Java Enterprise apps Heavy, JVM overhead
ecosystem

Node.js + Express JavaScript Real-time apps Fast, lightweight Weaker type safety

Quick dev, easy ML

Flask / FastAPI Python Data science & ML services Slower performance
integration

Windows/Enterprise
.NET Core C# High performance Smaller community
systems

Go Golang High-performance systems Fast, concurrent Steep learning curve

Serverless (e.g., AWS Event-driven or infrequent

Any (JS, Python, Java) No infra, cost-effective Cold starts, lock-in
Lambda) jobs