Skip to content

ADR 02 ‐ Microservices Architecture

Pablo García-Ovies Pérez edited this page Feb 20, 2024 · 1 revision

Status

  • Proposed
  • Accepted
  • Superseded

Context

The decision wheather to use or not a microservices architecture is driven by the need to address several challenges and requirements specific to the development of the WIQ application:

  • Flexibility: To accommodate future feature enhancements (such as non-mandatory requirements) and changes without disrupting the entire system, a more modular approach is required. It would also be helpful regarding that the dev team is big enough so more issolated modules could be beneficial in terms of organization / good practices.

  • Scalability: The application needs to handle varying levels of user activity, and a monolithic architecture may not scale efficiently to meet demand spikes.

  • Decoupling: Minimizing dependencies between different parts of the system is crucial for fault isolation and resilience given the need of manage diverse functionalities within the same project.

  • Technology Diversity: The system may require different technologies and tools for various functionalities, and microservices allow for flexibility in technology selection for each module.

  • API-based Communication: Providing access to user and question data through APIs necessitates an architecture that supports service-oriented communication between components.

Decision

We will adopt a microservices architecture for the WIQ application.

Consequences

  • Benefits:

    • Scalability: Microservices enable horizontal scaling of individual components, optimizing resource usage and performance.
    • Flexibility: Each microservice can be developed, deployed, and scaled independently, facilitating agility and ease of use in development and maintenance.
    • Decoupling: Services operate independently, reducing the impact of failures and enabling easier maintenance and updates.
    • Technology Diversity: Microservices allow for the use of different technologies, enabling the selection of the most appropriate tools for each service.
  • Trade-offs:

    • Increased Complexity: Managing multiple services introduces complexity in deployment, monitoring, and orchestration.
    • Overhead: Communication overhead and operational overhead associated with managing microservices may impact performance and resource utilization.
    • Operational Challenges: Monitoring, logging, CI/CD and ensuring consistency across services become more challenging in a distributed environment.

Compliance

To ensure compliance with the decision to use microservices, the following measures will be taken:

  • Clear Service Boundaries: Define clear boundaries between microservices to promote modularity and minimize interdependencies.
  • Tasks Taxonomy: Distribute work between the members of the team so it is clear what topics belong to each service / module.

Notes

  • Original Author: @PabloGOP
  • Approval date: 20/02/2024
  • Approved by: MM 08
  • Superseded date: N/A
  • Last modified date: N/A
  • Modified by: N/A
  • Last modification: N/A