Registry Service
Core platform component acting as the control plane. Stores service topology, node endpoints, and API metadata.
Learn about the RegistrySpring Middleware
A platform layer for Spring Boot microservices
Spring Middleware provides a registry-driven platform that standardizes infrastructure while keeping services autonomous and architecture explicit. It enables declarative service communication, distributed GraphQL federation, and automatic batching of cross-service queries—solving N+1 problems at the platform level instead of resolver level.
Platform runtime infrastructure
Spring Middleware runs on top of standard infrastructure components that provide messaging, distributed coordination, and state sharing across services.
Required infrastructure
Spring Middleware is a platform layer that depends on external infrastructure components. These are not optional libraries — they are part of the runtime model.
RabbitMQ (Infrastructure)
Required messaging infrastructure used for node-level communication and event propagation across the platform.
Messaging with RabbitMQRedis (Infrastructure)
Required for shared state and coordination. Used by the Registry for distributed topology management and runtime coordination.
See Redis moduleThese components are part of the platform runtime. Services remain autonomous, but rely on this shared infrastructure to achieve consistent behavior across the system.
What it is
Spring Middleware is not another wrapper around Spring Boot. It is a platform layer that sits between service code and infrastructure, so repeated platform concerns do not have to be rebuilt in every application.
Application business logic
↓
Spring Middleware platform layer
↓
Spring Boot / transport / infrastructureWhy it exists
In real distributed systems, the same infrastructure problems keep returning: service discovery, client wiring, schema metadata, context propagation, error normalization, messaging setup, and runtime topology visibility. Spring Middleware turns those into explicit platform capabilities.
Core platform capabilities
The platform focuses on infrastructure concerns that usually become fragmented or inconsistently implemented across services.
Registry-driven topology
Services register nodes, REST resources, and GraphQL schemas so the runtime topology remains explicit, discoverable, and recoverable.
Declarative service communication
Middleware clients resolve target services through the registry and apply consistent request context propagation and remote error handling.
GraphQL federation
Services publish schemas independently and the platform composes them into a unified GraphQL view through a federated gateway model.
Messaging infrastructure
Kafka and RabbitMQ integrations are treated as platform concerns rather than per-service boilerplate wiring.
Unified error and tracing model
Request identifiers, span propagation, and structured error handling remain consistent across service boundaries.
Reusable data modules
Mongo, JPA, Redis, cache, and shared infrastructure utilities support common persistence and coordination patterns across services.
Architecture first
The project is built around explicit architecture, not hidden behavior. The control plane remains visible, runtime state is discoverable, and services stay autonomous even while sharing common platform infrastructure.
Control plane
The Registry Service maintains topology, schema metadata, registered REST resources, and node state. Services continuously reconcile with it so platform metadata converges back to the real cluster state.
Data plane
Application services expose APIs, call each other through declarative clients, publish schemas, consume messaging infrastructure, and remain focused on domain behavior rather than repeated infrastructure plumbing.
Modular adoption
Spring Middleware is published as a modular ecosystem. Services can adopt the pieces they need while keeping versions aligned through the BOM.
Platform modules
Core platform pieces include the shared application layer, registry support, communication model, and GraphQL infrastructure.
Data modules
Redis, Mongo, JPA, and cache modules provide reusable integration patterns instead of ad hoc per-service implementations.
Messaging modules
RabbitMQ and Kafka modules support event-driven communication through reusable publishers, subscribers, and platform conventions.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.github.spring-middleware</groupId>
<artifactId>bom</artifactId>
<version>1.3.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>Start here
The fastest way to understand the project is to begin with the architectural model and then move to service bootstrapping.
About the author
Spring Middleware is designed and developed by Fernando Guardiola Ruiz, a senior backend architect focused on distributed systems, microservice platforms, and production-grade infrastructure design.
Build Spring microservices with a real platform layer
Explore the repository, import the BOM, and use the documentation to understand how Spring Middleware standardizes infrastructure without turning the system into hidden magic.