Microservices architecture - FAME-DEV/Java-Test GitHub Wiki

Microservices architecture is a software design approach where an application is built as a collection of small, independent services that each focus on doing one thing well. Each service:

  • Runs in its own process

  • Communicates via well-defined APIs (typically HTTP/REST)

  • Can be deployed independently

  • Can be written in different programming languages

  • Can use different data storage technologies

  • Key characteristics and benefits:

  • Independence and Loose Coupling

  • Services can be developed, deployed, and scaled independently

  • Teams can work autonomously on different services

  • Failures in one service don't directly affect others

  • Focused Purpose

  • Each service handles a specific business capability

  • Services are organized around business domains rather than technical layers

  • More maintainable and understandable codebase

  • Technology Flexibility

  • Different services can use different tech stacks

  • Teams can choose the best tools for each specific problem

  • Easier to adopt new technologies incrementally

  • Scalability

  • Services can be scaled independently based on demand

  • More efficient resource utilization

  • Better performance optimization opportunities

  • Common challenges:

  • Distributed System Complexity

  • Network latency

  • Service discovery

  • Distributed transactions

  • Data consistency

  • Operational Overhead

  • More moving parts to monitor and maintain

  • Complex deployment pipelines

  • Need for robust service discovery and load balancing

  • Testing Challenges

  • Integration testing becomes more complex

  • Need to handle service dependencies

  • More sophisticated testing strategies required

Here are the key principles of microservices architecture:

  • Single Responsibility

  • Each service handles exactly one core business capability

  • Services are scoped by business domain boundaries

  • Example: In an e-commerce system, separate services for order management, inventory, and customer profiles

  • Autonomy and Independence

  • Services can be developed, deployed, and scaled independently

  • Each service owns its data and business logic

  • No shared databases between services

  • Changes to one service shouldn't require changes to others

  • Decentralization

  • Teams have full ownership of their services

  • Decentralized data management - each service manages its own database

  • Decentralized governance - teams can choose appropriate technologies

  • Avoid sharing code or dependencies between services

  • API First Design

  • Services communicate through well-defined APIs

  • APIs are treated as first-class products

  • Clear contracts between services

  • Version management for backward compatibility

  • Smart Endpoints, Dumb Pipes

  • Business logic stays in the services (endpoints)

  • Communication channels (pipes) remain simple

  • Prefer simple protocols like REST over complex middleware

  • Avoid putting business logic in communication layers

  • Design for Failure

  • Services must be resilient to failures of other services

  • Implement circuit breakers and fallbacks

  • Design with eventual consistency in mind

  • Graceful degradation when dependencies fail

  • Infrastructure Automation

  • Automated deployment pipelines

  • Infrastructure as code

  • Continuous integration and delivery

  • Automated testing at all levels

  • Evolutionary Design

  • Services can evolve independently

  • Easy to replace or retire services

  • Support multiple versions of APIs when needed

  • Incremental improvements over big-bang changes