Architecture Overview

Sabu is organized as a microservices-based framework. The main idea is to divide carbon emissions workflows into independent services with focused responsibilities.

Each service is intended to have clear boundaries, explicit interfaces, and independent deployment options. Shared functionality is placed in reusable libraries rather than being duplicated across services.

Architectural goals

The architecture is designed around the following goals:

Goal	Meaning in Sabu
Modularity	Each service has a focused responsibility
Extensibility	New services can be added without redesigning the whole framework
Maintainability	Service-level concerns are separated from shared concerns
Interoperability	Services communicate through explicit interfaces
Reusability	Shared functionality is packaged as libraries
Deployability	Services can be packaged and executed independently

Services

A Sabu service is an independently developed runtime component. A service can expose an API, process input data, generate outputs, and be packaged for execution.

The main implemented service is currently jug_lca_buildings.

The following services are part of the framework direction but are not yet at the same architectural maturity:

• jug_gis_cities
• jug_gis_validation
• jug_sim_buildings

Shared libraries

Shared libraries provide reusable capabilities that can be imported by services.

Current shared libraries include:

• sabu-chassis
• citygisoo

These libraries are not standalone services. They support service implementation by providing reusable functionality.

API boundaries

Sabu services are intended to expose clear boundaries through APIs and schemas. This allows inputs and outputs to be validated and documented.

In the current implementation, jug_lca_buildings is the main example of this structure.

Containerization

Sabu services are designed to support isolated execution. Docker is used where appropriate to package service dependencies and runtime configuration.

Docker-based execution is especially useful for:

• testing a service in isolation,
• reducing environment differences,
• running the same service across machines,
• preparing services for future orchestration.

Current architectural maturity

The architecture is currently most fully applied in jug_lca_buildings.

The next architectural step is to apply the same design direction to jug_gis_cities and jug_gis_validation, so that geospatial preparation, validation, and emissions calculation can be documented and executed as a more consistent service chain.