System Architecture

The evolution of ArthemizLabs from a single deployment unit to a distributed, microservices-oriented platform.

Architecture Evolution

The ArthemizLabs platform has been designed to evolve through three distinct architectural phases. Each phase builds on the stability of the previous and introduces the complexity required to support the next stage of growth.

01 Monolith

Monolithic Foundation

The initial platform is built as a single deployable application. This approach enables rapid development, shared in-process state, and simplified deployment pipelines while the domain model is still being validated.

  • Single database, single process
  • In-process authentication with JWT validation middleware
  • Flat RBAC model enforced at the controller layer
  • Docker Compose for local development and initial production deployment
  • Nginx as a reverse proxy for TLS termination and routing
  • GitHub Actions CI pipeline for automated test and build
Client
-->
Nginx
-->
Application
(Monolith)
-->
PostgreSQL
02 Modular

Modular Decomposition

As the platform grows, the monolith is organized into clearly bounded modules with enforced internal APIs. Modules are deployed as discrete containers but remain coordinated through a shared orchestration layer.

  • Bounded modules: identity, commerce, operations, monitoring
  • Centralized JWT issuance via Arthemiz identity service
  • RBAC policies extracted to a dedicated authorization module
  • Redis introduced for distributed session caching and pub/sub
  • RabbitMQ for asynchronous inter-module messaging
  • Docker with named service networks isolating module communication
  • Nginx routing by path prefix to appropriate module containers
  • CI/CD pipeline extended with per-module build and test stages
Client
-->
Nginx
Gateway
Identity
(Arthemiz)
Commerce
(Vendas3D)
Operations
(OpsLedger)
Monitoring
(SystemHealth)
PostgreSQL
Redis
RabbitMQ
03 Microservices

Microservices Distribution

Modules that have demonstrated clear ownership, independent release cycles, and high load requirements are promoted to independent microservices. Each service is owned by a team, versioned independently, and communicates through well-defined contracts.

  • Independent services: each with its own repository, database, and CI pipeline
  • API Gateway handles authentication via JWT verification and routes to services
  • RBAC enforced at the gateway and re-validated at service boundaries
  • RabbitMQ as the central event bus for cross-service events
  • Redis per-service for local caching, preventing cross-service cache coupling
  • Nginx as the external load balancer with upstream health checks
  • Docker images published to a private registry and deployed via CI/CD
  • Distributed tracing for end-to-end request visibility across service hops
  • Service mesh (future) for mTLS, circuit breaking, and traffic policies

Core Infrastructure Components

JWT Authentication

JSON Web Tokens are issued by the Arthemiz identity service and validated at every service entry point. Tokens carry a minimal claim set (subject, roles, tenant) and are short-lived with refresh token rotation. Private key signing ensures token integrity across service boundaries.

RBAC Authorization

Role-Based Access Control governs all resource access across the platform. Roles are defined per-tenant and scoped to resource types. The authorization engine resolves permissions from JWT claims at the gateway and enforces them in each service, ensuring consistent policy application.

Docker and Containerization

All services run as Docker containers. Compose files define local development environments. Production deployments use isolated container networks, health checks, and restart policies. Container images are versioned and pinned for reproducible deployments.

Nginx

Nginx serves as the edge layer for TLS termination, HTTP/2 support, and reverse proxy routing. Configuration is versioned alongside application code. Rate limiting and request filtering are applied at this layer before traffic reaches application services.

RabbitMQ

RabbitMQ enables reliable asynchronous communication between services through topic exchanges and durable queues. Events such as user provisioning, order state changes, and audit entries are published and consumed by interested services without direct coupling.

Redis

Redis provides sub-millisecond caching for session tokens, rate limit counters, and frequently read configuration data. It also supports pub/sub patterns for real-time event notifications within a service boundary. Persistence is enabled for critical state.

CI/CD

GitHub Actions runs automated pipelines on every pull request and push to main. Pipelines include linting, unit and integration tests, container builds, vulnerability scans, and deployment to staging. Production deployments require a passing pipeline and manual approval gate.