Skip to main content

4. Break Sirius into smaller services

Date: 2020-12-01

Status

Accepted

Context

Sirius has grown organically over 7 years of development. Currently its main api service contains the majority of business logic across both LPA, Supervision domains and shared concerns like Search and user management. This combined with a previous approach of never cleaning up redundant code has made the Sirius codebase hard to work with. While we have done great things to clean up what we have, it’s become clear that the partitioning of various pieces of logic is not always clear and independent change to non-connected elements is often hard.

By splitting up Sirius into smaller services with more defined contracts we will be able to create more comprehensible services that are faster to iterate on without fear of unintended consequences. We will also be able to deploy compenents independently and reduce the need to build the entire container set to stand up local development. We will also be able to move to easier mocking of services during tests as we can mock http endpoints, reducing the need to stand up full services.

As more external services need access into Sirius, particularly external facing services like Digideps or the upcoming Modernised LPA it makes sense to start partitioning by business domain. So that rather than just being the data for the CMS the Sirius backend services become “the data for OPG”. This will reduce our need for translation layers such as the current opg-data services.

This work will also allow us to transition services to GO in smaller steps, following the strangler-fig pattern.

Decision

We will actively break down Sirius into smaller services allowing for easier partitioning of work based on the domain and function, thereby speeding up our ability to iterate.

Consequences

  • We will need to clearly define where elements of the domain can be partitioned off
  • We may have to run more internal migrations to move ownership of data from the main API container and Doctrine.
  • Services will need to be built with clear identifiers to map between them
  • We can use the pattern to assist in our move to golang
This page was last reviewed on 10 December 2024. It needs to be reviewed again on 10 June 2025 by the page owner #opg-sirius-develop .
This page was set to be reviewed before 10 June 2025 by the page owner #opg-sirius-develop. This might mean the content is out of date.