Microservices

High Overview

Category	Monolithic architecture	Microservices architecture
Design	Single code base with multiple interdependent functions	Independent software components with autonomous functionality that communicate with each other using APIs
Development	Requires less planning at the start, but gets increasingly complex to understand and maintain	Requires more planning and infrastructure at the start, but gets easier to manage and maintain over time
Deployment	Entire application deployed as a single entity	Every microservice is an independent software entity that requires individual containerized deployment
Debugging	Trace the code path in the same environment	Requires advanced debugging tools to trace the data exchange between multiple microservices
Modification	Small changes introduce greater risks as they impact the entire code base	You can modify individual microservices without impacting the entire application
Scale	You have to scale the entire application, even if only certain functional areas experience an increase in demand	You can scale individual microservices as required, which saves overall scaling costs
Investment	Low upfront investment at the cost of increased ongoing and maintenance efforts	Additional time and cost investment to set up the required infrastructure and build team competency. However, long-term cost savings, maintenance, and adaptability
Use Cases	Small to medium-sized projects Rapid prototyping and MVP development Tightly coupled components Resource constraints Low-usage applications for improving cost efficiency	Large and complex systems Scalability demands Technology diversity Independent deployment and continuous delivery High fault tolerance and resilience Large cross-functional development teams Rapid evolving requirements

Monolithic

Overview

Monolithic architecture is a single application that is built as a single unit. Is a singular, large computing network with one code base that couples all of the business concerns together. To make a change to this sort of application requires updating the entire stack by accessing the code base and building and deploying an updated version of the complete application.

• Monolithic applications initially offer advantages such as ease of development and deployment
• Challenges arise as teams grow, leading to blocked deploys, cross-team functionality issues, and difficulties with updates

As a result, monolithic applications are often difficult to scale and maintain and often migrate to a microservices architecture. This involves identifying and modifying tightly coupled entities, which is complex.

Modular Monolith

Monolithic applications can be transformed into modular monolith by starting with a single repository and clear boundaries between business contexts. Which will allow for easier transition to microservices architecture.

Advantages of Modular Monolith

• Bounded contexts in a modular monolith encompass independent business functions
• Isolating business contexts within a single codebase and database prevents future issues and facilitates changes
• Changes within a modular monolith are less costly compared to traditional monoliths, as data migration isn't necessary
• Communication between modules in a modular monolith should utilize events instead of direct method calls
• Techniques for maintaining data consistency and event management include emitting events, using databases, or employing message queues

Segregation by Feature

Microservices

Overview

Microservices are independent, and loosely coupled software components that perform specific tasks within a larger application, facilitating scalability, flexibility, and maintainability in software development. They organize the subdomains into one or more deployable/executable components.

Golden Rule

• we need to ensure that our microservices are independently deployable
• if we needed to update our country codes library, and have all services pick up the new data immediately, we'd need to redeploy all services at the moment the new library is available
  • this is a classic lock-step release, and exactly what we're trying to avoid with microservice architectures

Advantages

• Simple Components: Small, focused components, simplifying development and maintenance
• Team Autonomy: Teams should have the independence to develop, test, and deploy their software autonomously, enabling faster iterations and reducing dependencies on other teams
• Fast Deployment Pipeline: A rapid deployment pipeline facilitates quick feedback and frequent deployments
• Support for Multiple Technology Stacks: Applications may utilize various technologies within different subdomains, requiring developers to update the technology stack to maintain compatibility with current languages and frameworks
• Segregation by Characteristics: Segregating components based on characteristics like resource requirements, availability, and security enhances scalability, availability, and security, respectively
• Simple Interactions: Operations that involve local or straightforward interactions between components are easier to troubleshoot
• Efficient Interactions: Distributed operations involving numerous network round trips and large data transfers can be inefficient and should be minimized for optimal performance
• Prefer ACID over BASE: Implementing operations as ACID transactions rather than eventually consistent sagas simplifies development and maintenance
• Minimize Runtime Coupling: Reducing runtime coupling maximizes availability and minimizes latency for operations, improving overall system performance
• Minimize Design Time Coupling: Decreasing design time coupling reduces the likelihood of services needing to be changed simultaneously, enhancing productivity and flexibility in development

Principles

• Organized around Business Capabilities

  • Traditional division based on technology layers leads to cross-team projects for even simple changes due to Conway's Law (the way people within an organization communicate influences the structure of the systems they build)
  • Microservice approach focuses on organizing services around business capabilities
  • Cross-functional teams with skills for entire development process

• Size of Microservices

  • Varies, often sized around Amazon's "Two Pizza Team" concept (organizing teams small enough that they can be fed with just two pizzas)
  • Ranges from a dozen people supporting several services to a smaller team per service

• Product Ownership

  • Microservice teams own products over their full lifetime
  • Inspired by Amazon's "you build, you run it" philosophy
  • Emphasizes ongoing relationship and enhancing business capabilities

• Communication Structure

  • Smart endpoints and dumb pipes approach
  • Microservices use simple protocols like HTTP request-response and lightweight messaging

• Comparison with SOA

  • Microservices similar to some aspects of Service Oriented Architecture (SOA) but with distinct differences by focusing on avoiding pitfalls of traditional SOA implementations

• Decentralized Governance

  • Encourages using right tools for the job rather than standardizing on single technology platforms
  • Promotes producing useful tools shared within teams, similar to internal open source model

• Infrastructure Automation

  • Utilizes extensive automation techniques for building, deploying, and operating microservices
  • Enables teams to manage infrastructure efficiently and deploy software frequently

• Design Considerations

  • Emphasis on failure tolerance, real-time monitoring, and asynchronous communication
  • Supports evolutionary design, modular decomposition, and granular release planning
  • Prefers tolerant services over heavy versioning for managing changes

Best Practices

• Use separate data storage for each microservice
• Keep code at a similar level of maturity
• Separate build for each microservice
• Assign each microservice with a single responsibility
• Deploy into containers
• Design stateless services
• Adopt Domain-Driven Design (DDD)
• Design micro frontend
• Orchestrating microservices with Kubernetes

Architecture

Aspect	On-Premises	Infrastructure-as-a-Service (IaaS)	Platform-as-a-Service (PaaS)	Software-as-a-Service (SaaS)
Application	🟢	🟢	🟢	🟣
Data	🟢	🟢	🟢	🟣
Runtime	🟢	🟢	🟣	🟣
Middleware	🟢	🟢	🟣	🟣
O/S	🟢	🟢	🟣	🟣
Virtualization	🟢	🟣	🟣	🟣
Servers	🟢	🟣	🟣	🟣
Storage	🟢	🟣	🟣	🟣
Networking	🟢	🟣	🟣	🟣
🟢 Managed by you 🟣 Managed by other

Architecture Overview

Overview

Visualization

Specs

Load Balancer: Distributes traffic to multiple backend services CDN (Content Delivery Network): Speeds up content delivery by storing static content on distributed servers API Gateway: Routes requests to relevant services, interacts with identity provider and service discovery Identity Provider: Manages user authentication and authorization Service Registry & Discovery: Registers and finds microservices, used by API gateway to locate services Management: Monitors services Microservices: Independently deployed and maintained in separate domains, each with its own database. Communicate via REST API or RPC

Common Setup

Pre-Production	Production
Stack Define API: Establish frontend-backend contract using Postman/OpenAPI Develop UI: Node.js/React Develop Microservices: Java/Python/Go Test: Unit test framework and Jenkins/Github Actions/CircleCI/Gitlab CI Build: Package code into Docker images for microservices deployment	Stack Load Balancer: NGINX CDN: CloudFront/Cloudflare API Gateway: Zookeeper/Eureka for service discovery Full-Text Search: ElasticSearch Cache: Redis Communications: Kafka or RPC for service communication Management & Monitoring: Prometheus/Grafana/Elastic Stack/Kubernetes Persistence Relational DB: MySQL/PostgreSQL Object Store: S3/GCS/Azure Blob Cloud Deployment: GCP/AWS/Azure

Architectural Layers

Aspect	Micro Frontends	Microservices	Data Mesh
Visualization
Definition	Architectural style for frontend development, breaking down a frontend app into smaller, manageable pieces	Architectural style for backend development, breaking down a monolithic app into smaller, independent services	Architectural approach for data management, decentralizing data ownership to domain-specific teams
Focus	User interface components	Business capabilities	Data ownership
Purpose	Enable multiple teams to work on different parts of a frontend application independently	Enable independent development, deployment, and scaling of backend services	Address challenges in centralized data architectures by decentralizing data ownership and governance
Key Principles	Technology agnostic Isolate team code Independent deployment Clear ownership	Single responsibility principle Decentralized data management Independent deployment Scalability	Domain-oriented data ownership Data as a product Self-serve data infrastructure Federated governance
Benefits	Faster development cycles Reduced complexity Independent deployments Better team autonomy	Scalability Flexibility Fault isolation Technology diversity	Improved data quality Faster data access Scalability Better alignment with business domains
Challenges	Increased complexity in integration Potential for inconsistent user experience Requires strong governance	Increased complexity in managing multiple services Potential for data inconsistency Requires strong governance	Requires cultural shift Potential for data silos Requires strong governance and collaboration
Deployment	Independent deployments
Collaboration	Requires cross-team collaboration and communication

Repos

Aspect	Monorepo	Multi-Repo
Repository Structure	Single repository containing multiple projects/packages	Separate repositories for each project/package
Dependency Management	Shared dependencies managed centrally	Each repository manages its own dependencies
Build & CI/CD	Unified build and CI/CD pipelines	Separate pipelines for each repository
Code Ownership	Clear ownership and responsibility	Ownership can be more fragmented and decentralized
Deployment	Single deployment process	Each repository may have its own deployment process
Performance	Can lead to larger repository size and slower operations	Smaller repositories can have faster operations
Testing	Easier integration testing across projects/packages	Testing is more isolated, might require more integration efforts
Scaling	Might face scalability challenges with a very large codebase	Easier to scale by adding more repositories
Overhead	Potentially higher overhead due to managing a large codebase	Lower overhead for smaller repositories

Project Structure

Frontend

Overview

Aspect	File Type Based	Module/Feature Based	Atomic Design	Clean Architecture
Focus	File types (JSX, CSS, tests)	Functional modules, features	UI component hierarchy	Business logic separation (layers)
Scalability	Small to medium projects	Medium to large projects	Scalable for complex UIs	Very scalable, promotes separation of concerns
Use Cases	Simple apps, prototypes	Complex features, e-commerce applications	Component libraries, design systems	Large-scale enterprise applications with strict separation

File Type Based

src/
├── components/
│   ├── Avatar/
│   │   ├── Avatar.jsx
│   │   ├── Avatar.test.js
│   ├── Button/
│   │   ├── Button.jsx
│   │   ├── Button.test.js
│   └── TextField/
│       ├── TextField.jsx
│       └── TextField.test.js
├── contexts/
│   └── UserContext/
│       └── UserContext.js
├── hooks/
│   └── useMediaQuery/
│       └── useMediaQuery.js
├── pages/
│   ├── UserProfile/
│   │   ├── components/
│   │   │   └── UserProfileComponent/
│   │   │       ├── UserProfileComponent.jsx
│   │   │       └── UserProfileComponent.test.js
│   │   ├── UserProfile.jsx
│   │   └── UserProfile.test.js
│   └── index.js
├── routes/
│   ├── routes.jsx
│   └── routes.test.js
├── utils/
│   └── custom-util/
│       ├── index.js
│       ├── customUtil.js
│       └── index.test.js
├── services/
│   └── custom-service/
│       ├── index.js/
│       ├── customService.js/
│       └── index.test.js
├── App.jsx
└── index.js

Module / Feature Based

src/
├── components/
│   ├── Avatar/
│   │   ├── Avatar.jsx
│   │   └── Avatar.test.js
│   ├── Button/
│   │   ├── Button.jsx
│   │   └── Button.test.js
│   └── TextField/
│       ├── TextField.jsx
│       └── TextField.test.js
├── contexts/
│   └── UserContext/
│       └── UserContext.js
├── hooks/
│   └── useMediaQuery/
│      └── useMediaQuery.js
├── features/
│   ├── Home/
│   │   ├── components/
│   │   │   └── UserProfileComponent/
│   │   │       ├── UserProfileComponent.jsx
│   │   │       ├── UserProfileComponent.test.js
│   │   ├── utils/
│   │   ├── services/
│   │   ├── hooks/
│   │   ├── contexts/
│   │   ├── views/
│   │   │   └── HomeView.jsx
│   │   └── pages/
│   │       └── HomePage.jsx
│   └── index.js
├── utils/
│   └──  custom-common-util/
│       ├── index.js/
│       └── index.test.js
├── services/
│   └── custom-common-service/
│       ├── index.js/
│       ├── custom-common-service.js/
│       └── index.test.js
├── App.jsx
└── index.js

Atomic Design

src/
├── components/
│   ├── atoms/ ← Single UI elements
│   │   └── Button/
│   │      ├── Button.js
│   │      └── Button.css
│   ├── molecules/ ← Groups of atoms with a function
│   │   └── SearchBar/
│   │       ├── SearchBar.js
│   │       └── SearchBar.css
│   ├── organisms/ ← Complex components from molecules/atoms
│   │   ├── Header/
│   │   │  ├── Header.js
│   │   │  └── Header.css
│   │   └── ProductList/
│   │       ├── ProductList.js
│   │       └── ProductList.css
│   └── templates/ ← Layouts for arranging UI on a page
│       └── DefaultTemplate/
│           ├── DefaultTemplate.js
│           └── DefaultTemplate.css
├── pages/ ← Final product with real content in templates
│   ├── HomePage/
│   │   ├── HomePage.js
│   │   └── HomePage.css
│   └── AboutPage/
│       ├── AboutPage.js
│       └── AboutPage.css
├── shared/
└── public/

Clean Architecture

src/
├── domain/
│   ├── models/
│   │   └── User.js/
│   └── services/
│       └── User.service.js/
├── infrastructure/
│		├── components/
│		│   ├── Avatar/
│		│   │   ├── Avatar.jsx
│		│   │   └── Avatar.test.js
│		│	  └── UserProfile/
│		│       ├── UserProfile.jsx
│		│       └── UserProfile.test.js
│		├── http/
│		│   ├── dto/
│		│   │   └── userDto.js/
│		│   └── http.js
│		└── repositories/
│		    └── user.repository.js/
├── App.jsx
└── index.js

Backend

Overview

Aspect	Layered Architecture	Feature-Based Architecture	Clean / Hexagonal Architecture (DDD)
Core Concept	Segregation into layers such as Presentation, Business Logic, Data Access	Organization around features/modules with self-contained folders	Focus on domain-driven design, with clear boundaries between domain and application layers
Dependencies	Layer dependencies are hierarchical	Feature modules are more independent but may share utilities	Dependent on use cases, but typically focuses on domain logic being independent of infrastructure
Scalability	Can become rigid and hard to scale with increasing complexity	Scales well with the growth of features, easier to manage	Provides a scalable structure, but may require careful management of dependencies
Domain-Centric Focus	Less emphasis on domain modeling, more on technical layers	Features encapsulate domain logic but may not focus solely on it	Central focus on domain modeling, with application logic structured around it
Ease of Maintenance	Changes may require modifications across multiple layers	Easier maintenance due to encapsulation within features	Maintenance focused on the domain model, with changes reflected through adapters

Layered Architecture

project_name/
├── src/
│   ├── config/
│   │   ├── database
│   │   └── app
│   ├── controllers/
│   │   ├── UserController
│   │   └── ProductController
│   ├── models/
│   │   ├── User
│   │   └── Product
│   ├── repositories/
│   │   ├── UserRepository
│   │   └── ProductRepository
│   ├── services/
│   │   ├── UserService
│   │   └── ProductService
│   ├── middlewares/
│   │   ├── AuthenticationMiddleware
│   │   └── AuthorizationMiddleware
│   ├── exceptions/
│   │   ├── CustomException
│   │   └── HttpException
│   ├── utils/
│   │   ├── Validation
│   │   └── HelperFunctions
│   ├── routes/
│   │   ├── web
│   │   └── api
│   └── views/
│       ├── user/
│       │   └── profileView
│       └── product/
│           └── listView
├── tests/
│   ├── Unit/
│   │   ├── UserControllerTest
│   │   └── ProductControllerTest
│   └── Feature/
│       ├── UserFeatureTest
│       └── ProductFeatureTest
├── database/
│   ├── migrations/
│   │   ├── 20240101000000_create_users_table
│   │   └── 20240102000000_create_products_table
│   └──  seeds/
│        ├── UsersTableSeeder
│        └── ProductsTableSeeder
├── vendor/
├── storage/
└── config/
    ├── app
    └── database

Feature Based Architecture

project_name/
├── src/
│   ├── Features/
│   │   ├── User/
│   │   │   ├── Controllers/
│   │   │   │   └── UserController
│   │   │   ├── Models/
│   │   │   │   └── User
│   │   │   ├── Repositories/
│   │   │   │   └── UserRepository
│   │   │   ├── Services/
│   │   │   │   └── UserService
│   │   │   ├── Routes/
│   │   │   │   ├── web
│   │   │   │   └── api
│   │   │   └───Views
│   │   │       └── profileView
│   │   └── Product/
│   │       ├── Controllers/
│   │       │   └── ProductController
│   │       ├── Models/
│   │       │   └── Product
│   │       ├── Repositories/
│   │       │   └── ProductRepository
│   │       ├── Services/
│   │       │   └── ProductService
│   │       ├── Routes/
│   │       │   ├── web
│   │       │   └── api
│   │       └───Views/
│   │           └── listView
│   ├── Shared/
│   │   ├── Helpers/
│   │   │   └── Validation
│   │   ├── Exceptions/
│   │   │   └── CustomException
│   │   ├── Middleware/
│   │   │   └── AuthenticationMiddleware
│   │   ├── Services/
│   │   │   └── AuthService
│   │   ├── Models/
│   │   │   └── BaseModel
│   │   └── Repositories/
│   │       └── BaseRepository
│   └── Routes/
│       ├── web
│       └── api
├── tests/
│   ├── Unit/
│   │   ├── User/
│   │   │   └── UserControllerTest
│   │   └── Product/
│   │       └── ProductControllerTest
│   └───Feature/
│       ├── User/
│       │   └── UserFeatureTest
│       └── Product/
│           └── ProductFeatureTest
├── database/
│   ├── migrations/
│   │   ├── 20240101000000_create_users_table
│   │   └── 20240102000000_create_products_table
│   └───seeds/
│       ├── UsersTableSeeder
│       └── ProductsTableSeeder
├── vendor/
└── config/
    ├── app
    └── database

Clean / Hexagonal Architecture (DDD)

project_name/
├── src/
│   ├── Application/
│   │   ├── Services/
│   │   │   ├── UserService
│   │   │   └── ProductService
│   │   └── UseCases/
│   │       ├── User/
│   │       │   ├── CreateUserUseCase
│   │       │   └── GetUserUseCase
│   │       └── Product/
│   │           ├── CreateProductUseCase
│   │           └── GetProductUseCase
│   ├── Domain/
│   │   ├── Entities/
│   │   │   ├── User
│   │   │   ├── Product
│   │   └── Repositories/
│   │       ├── UserRepositoryInterface
│   │       └── ProductRepositoryInterface
│   └── Infrastructure/
│       └── Persistence/
│           └── Repositories/
│               ├── EloquentUserRepository
│               └── EloquentProductRepository
├── tests/
│   ├── Unit/
│   │   ├── Application/
│   │   │   ├── Services/
│   │   │   │   ├── UserServiceTest
│   │   │   │   └── ProductServiceTest
│   │   │   └── UseCases/
│   │   │       ├── User/
│   │   │       │   ├── CreateUserUseCaseTest
│   │   │       │   └── GetUserUseCaseTest
│   │   │       └── Product/
│   │   │           ├── CreateProductUseCaseTest
│   │   │           └── GetProductUseCaseTest
│   │   ├── Domain/
│   │   │   ├── Entities/
│   │   │   │   ├── UserTest
│   │   │   │   └── ProductTest
│   │   │   └── Repositories/
│   │   │       ├── UserRepositoryTest
│   │   │       └── ProductRepositoryTest
│   │   └── Infrastructure/
│   │       └── Persistence/
│   │           └── Repositories/
│   │               ├── EloquentUserRepositoryTest
│   │               └── EloquentProductRepositoryTest
│   └── Feature/
│       ├── User/
│       │   └── UserFeatureTest
│       └── Product/
│           └── ProductFeatureTest
├── database/
│   ├── migrations/
│   │   ├── 20240101000000_create_users_table
│   │   └── 20240102000000_create_products_table
│   └── seeds/
│       ├── UsersTableSeeder
│       └── ProductsTableSeeder
├── vendor/
└── config/
    ├── app
    └── database

Migration

Process

• Discovering system operations

  • Analyzing existing monolithic architecture
  • Identifying functionalities and dependencies
  • Documenting system components, interactions, and data flows
  • Conducting interviews with stakeholders to understand business requirements
  • Profiling system performance and resource utilization
  • Assessing scalability and maintainability issues in the current architecture
  • Generating system documentation and diagrams (e.g., entity-relationship diagrams, flowcharts)

• Defining subdomains

  • Use domain-driven design approach
  • Identifying business capabilities and boundaries
  • Decomposing the monolithic system into cohesive subdomains
  • Prioritizing subdomains based on business impact and complexity
  • Defining bounded contexts for each subdomain
  • Documenting subdomain boundaries, responsibilities, and contexts

• Designing services and their collaborations

  • Selecting appropriate communication protocols (e.g., REST, gRPC, GraphQL, Publish-Subscribe messaging)
  • Defining service interfaces and contracts
  • Choosing technology stacks for individual services
  • Designing fault-tolerant and resilient services
  • Implementing event-driven architectures or choreographed workflows
  • Establishing service discovery and registry mechanisms
  • Developing API gateways for routing and security
  • Implementing circuit breakers and retries for robustness
  • Designing data consistency strategies (e.g., eventual consistency, transactional boundaries)
  • Defining service versioning and backward compatibility policies

• Evaluating a microservice architecture

  • Performing architectural reviews and inspections
  • Conducting proof-of-concept implementations
  • Analyzing trade-offs between microservices and monolithic architectures
  • Evaluating scalability, performance, and latency requirements
  • Assessing operational overhead and deployment complexities
  • Conducting cost-benefit analysis of microservices adoption
  • Benchmarking against key performance indicators (KPIs) and service level objectives (SLOs)
  • Considering organizational readiness and cultural implications

• Refactoring a microservice architecture

  • Identifying code smells and anti-patterns in the existing architecture
  • Decomposing monolithic codebase into microservices
  • Applying domain-driven design principles for service boundaries
  • Implementing continuous integration and continuous deployment (CI/CD) pipelines
  • Automating testing, deployment, and monitoring processes
  • Establishing DevOps practices for collaboration and feedback loops
  • Implementing distributed tracing and logging for observability
  • Refactoring data storage and access patterns
  • Ensuring backward compatibility and data migration strategies
  • Documenting refactoring decisions and outcomes

Service Decomposition

Overview

Aspect	Decompose by Business Capability	Decompose by Subdomain	Self-contained Service	Service per Team	Strangler Application	Anti-corruption Layer
Definition	Breaks down the application into services based on business capabilities or functions	Splits services based on different subdomains or components of the business	Each service is independent and complete in itself, reducing dependencies	Each team is responsible for one or more services, allowing for ownership and autonomy	A new system slowly replaces the old one by gradually taking over its functionalities	Creates a layer between two services to ensure that changes in one do not affect the other
Complexity	Medium. Requires a good understanding of business capabilities	High. Requires a deep understanding of the domain and its subdomains	High. Each service must be self-sufficient	Low. Teams have full control over their services	Medium. Requires careful planning and incremental implementation	Medium. Requires understanding of both services involved
Use Cases	Large applications with distinct business functions	Complex domains with distinct subdomains	Applications where each service can operate independently	Teams with specific domain knowledge or skills	Legacy systems that need to be replaced	Preventing unwanted dependencies between services

Decompose by Subdomain / Business Capability

• Stable Architecture: Ensure the architecture is robust and consistent, minimizing disruptions and failures
• Cohesive Services: Services should focus on a specific set of closely related functions, enhancing clarity and maintainability
• Common Closure Principle: Group together components that are likely to change together, reducing the ripple effect of modifications across the system
• Loose Coupling: Services should expose clear APIs to interact with, allowing for flexibility in implementation changes without impacting clients
• Testability: Each service should be designed to be easily testable, facilitating quality assurance and reliability
• Scalable Team Size: Services should be small enough that they can be developed and managed effectively by a team of 6-10 people, promoting efficiency and communication
• Autonomous Teams: Teams responsible for services should have the autonomy to develop, deploy, and maintain their services independently, minimizing dependencies and streamlining workflows

Self-Contained Service

Pros

• Improved availability and response time

Cons

• Increased cost and complexity of using CQRS
• Increased complexity of using sagas
• Less straightforward API when using sagas

Service per Team

Pros

• Facilitates autonomous team work with minimal coordination
• Promotes loose coupling between teams
• Achieves autonomy and loose coupling with fewer services
• Enhances code quality through long-term ownership

Cons

• Teams may not always align with end user features
• Implementing cross-service features becomes more complex and requires collaboration between teams

Strangler Pattern

• Identify the system boundary you want to re-architect

• Create a facade

  • During system re-architecture, it's crucial that clients remain unaffected. To achieve this, the facade should align with the existing system API, providing a seamless transition for users
  • API of the new service needs to be meticulously crafted to maintain backward compatibility with the legacy API. Any potential breaking changes to the new service's API should only be implemented after the re-architecture process is complete

• Re-architect
  • Implement the new service and integrate it with the strangler facade
  • Dark launch the new service by diverting traffic between the new and legacy implementations
  • Initially, return responses from the legacy implementation while monitoring the behavior of the new implementation
  • Optionally, employ continuous deployment to deploy partial implementations of the new service to gain confidence and reduce risk

• Cutover
  • Once confident in the new implementation, switch production traffic to be served from the new implementation
  • Retain the legacy implementation for easy rollback if necessary

• Clean up
  • Delete the legacy code that has been replaced once the new system is established

• Migrate clients to the new API and remove the strangler facade
  • Manage the transition to the new API, potentially requiring breaking changes to clients
  • Expose the new API while maintaining the strangler facade for large client bases
  • Monitor usage of the strangler facade and assist clients in migrating to the new API
  • Remove the strangler facade once it's no longer in use

Branch by Abstraction

Steps

• Create an abstraction for the functionality that needs to be replaced
• Modify clients of the existing functionality to use the new abstraction
• Develop a new implementation of the abstraction with the reworked functionality
• Switch over to using the new implementation by adapting the abstraction
• Once the transition is complete and the new implementation is proven, clean up the abstraction
• Remove the old implementation once it's no longer needed

Parallel Run

• Instead of solely calling either the old or new implementation, both are called simultaneously
• This enables comparison of results to ensure equivalence
• Despite calling both, only one implementation is regarded as the "source of truth" at any moment
• Initially, the old implementation serves as the source of truth until ongoing verification validates the reliability of the new implementation
• This technique verifies not only the equivalence of results but also ensures that the new implementation operates within acceptable nonfunctional parameters

Decorating Collaborator

• It enables attaching new functionality to an object without the object being aware of it
• By using a decorator, it seems as if the monolith is directly communicating with services, without altering the monolith itself
• Instead of intercepting calls before reaching the monolith, the calls proceed normally
• After the call, based on the result, external microservices can be invoked through any chosen collaboration mechanism

Change Data Capture

• It involves reacting to changes made within a datastore rather than intercepting and acting on calls made into the monolith
• The effectiveness of change data capture relies on coupling the underlying capture system to the monolith's datastore
• Change data capture serves as a useful, versatile pattern, particularly for scenarios involving data replication
• In the context of microservices migration, this approach is most beneficial when there's a need to respond to data changes within the monolith, but it's not feasible to intercept them at the system's perimeter using techniques like strangler or decorator, nor is it possible to modify the underlying codebase

Scale