M3 - Overview
M3 - Overview
Created by,
Sanju Abraham Binu
● Spring Boot is an open-source Java-based framework designed to simplify
○ Main Features:
○ In Spring Boot, configuration refers to how you set up and customize your application’s behavior,
○ Spring Boot simplifies this by providing default configurations out of the box, but you can easily
such as:
■ Database connections.
■ Server ports.
■ Logging levels.
● Auto-configuration in Spring Boot
properties.
○ Benefits of Auto-configuration:
■ Faster development.
○ Responsibilities:
○ Benefits:
● Imagine you have multiple small services working together, like pieces of a puzzle, to
make an application run. Instead of manually telling each service where the others are,
service discovery helps them "discover" or find each other on their own.
● This is especially useful in microservices architecture, where services are constantly being
● Tools like Eureka, Zookeeper, or Consul are often used to manage this discovery process.
● What is Service Discovery?
other services.
○ Service Registry: Central server that maintains service metadata and enables discovery.
○ Heartbeat Mechanism: Services periodically send heartbeats to show they are alive.
● Eureka Workflow
○ How it Works:
■ Health Monitoring: Eureka removes services that are unhealthy or have failed.
● Decomposition Guidelines:
○ Focus on the verbs and actions within the business problem as guideline used to identify and decompose a
● Service Granularity:
○ Service granularity refers to how much functionality or responsibility a service handles in an application,
○ It defines whether a service is broad and handles many tasks (coarse-grained) or focused and handles a
○ The purpose of establishing service granularity in a microservice architecture is to define the scope and
○ Zookeeper:
■ Coordination and service discovery platform that also manages distributed configuration.
○ Consul:
○ When to Use: Choose based on your ecosystem, scalability needs, and complexity.
○ Decomposing a Monolith:
■ When decomposing a monolithic application like EagleEye into microservices, you start with
Identify nouns and verbs in the business problem to determine service boundaries
● What is an API Gateway?
○ Single Entry Point: All requests flow through the API Gateway.
○ Composition: Aggregates responses from multiple services and composes them into a
single output.
○ Coarse-grained Services: Easier to manage but may lead to too much responsibility in one
service.
communication.
● Coarse-grained Microservices:
boundaries
● Service Design:
○ The microservice manages data across a large number of tables can be the primary
○ Look for actions (verbs) that suggest separate operations is the best guideline helps
networked applications.
○ Use HTTP Verbs: GET for reading, POST for creating, PUT for updating, DELETE for removing
resources.
○ Status Codes: Use appropriate HTTP status codes (200 OK, 404 Not Found, 500 Server Error).
○ Data Format: Use JSON for request/response bodies for easy parsing and interoperability.
○ REST Guidelines:
■ Use standard HTTP verbs and URIs to represent resources is the strategy should be adopted when
○ Problem: Services are calling each other frequently, leading to tight coupling and
interdependencies.
○ Microservices are heavily interdependent and call each other frequently to complete user
○ Small Applications:
■ Monolithic design may be simpler and more effective for small-scale apps.
● Avoid Microservices:
○ The complexity and cost of building distributed systems may outweigh the benefits in those
○ Monitoring: Implement monitoring tools (Prometheus, Grafana) to track service health and
performance.
○ Versioning APIs: Version APIs to manage backward compatibility when updating services.
Summary
● The primary role of an architect in microservices architecture is to provide a working model
of the problem to be solved.
● Centralizing data storage is NOT a key focus for an architect when building a microservices
architecture.
● To decompose a business problem into microservice candidates, focus on the verbs and
actions within the business problem.
● The purpose of establishing service granularity in a microservice architecture is to define
the scope and responsibilities of each microservice.
● Starting with coarse-grained microservices and refactoring to finer-grained ones is
recommended to avoid premature complexity and help identify proper service boundaries.
● If a microservice manages data across a large number of tables, it may be too
coarse-grained.
● When decomposing a monolithic application like EagleEye into microservices, it's
best to identify nouns and verbs in the business problem to determine service
boundaries.
● Designing intuitive service interfaces in microservices should embrace the REST
philosophy with standard HTTP verbs (GET, POST, PUT, DELETE).
● If microservices are heavily interdependent and call each other frequently, it
indicates that the microservices are too fine-grained.
● The complexity and cost of building distributed systems often outweigh the
benefits for small, departmental-level applications, making microservices less
suitable for such scenarios.
● A new microservice should be created by looking for actions (verbs) that suggest
separate operations in the business problem.
● The right strategy for defining service interfaces is to use standard HTTP verbs
and URIs to represent resources.
● Microservices might be too fine-grained if they frequently communicate with other
microservices to complete a single request.