Spring Middleware is organized as a modular platform for Spring Boot microservices. It provides reusable modules for core infrastructure, data access, messaging, and platform services, allowing incremental adoption while maintaining consistent runtime behavior across services.
This page is the map of the platform. It shows how Spring Middleware is organized into reusable module groups, how those groups fit together, and where the platform documentation explains the runtime behavior around communication, registry, errors, security, logging, and messaging.
Spring Middleware is distributed through a BOM so services can keep versions aligned while still depending only on the modules they need. The goal is consistency of infrastructure behavior, not forcing every service to carry the entire platform.
The platform is published via Maven Central and managed through a BOM. That keeps module versions coherent across services and reduces dependency drift.
<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><dependencies>
<dependency>
<groupId>io.github.spring-middleware</groupId>
<artifactId>app</artifactId>
</dependency>
<dependency>
<groupId>io.github.spring-middleware</groupId>
<artifactId>kafka-core</artifactId>
</dependency>
</dependencies>The platform is organized into a few clear module families. Each family solves a different part of the infrastructure model.
Foundational runtime pieces used across the platform, including shared API, application support, common abstractions, and core models.
commonsapiappmodel-api / model-coreview-api / view-coreDatabase and cache integrations that bring dynamic search, distributed maps, locks, and reusable data access infrastructure into the platform layer.
Modules that make the platform discoverable and topology-aware, including registry services and GraphQL-related components.
A service usually depends on a small subset of modules, while the broader platform documentation explains how those modules behave at runtime.
Some modules are better understood through dedicated capability pages because they combine code, runtime behavior, and platform conventions.
Explicit orchestration of execution flows with support for pause and resume, dynamic routing, timeout handling, and external event continuation.
Kafka and RabbitMQ as platform-aligned messaging capabilities.
Distributed schema registration, composition, links, and gateway behavior.
Publishers, subscribers, event envelopes, retries, and dead-letter behavior.
Producers, consumers, handlers, listeners, acknowledgement, and lifecycle control.
Not everything is a module page. Some topics describe how the platform behaves across modules and services.
Control plane, service topology, node registration, REST metadata, and GraphQL schema discovery.
communication guideerrors guideclient-security guidelogging guideSeveral capabilities are already documented at module level and can be linked from here as focused deep dives.
Dynamic search capabilities and reusable query composition for MongoDB-backed services.
Dynamic search capabilities and reusable query infrastructure for relational persistence.
Distributed maps, locks, and reusable Redis abstractions for platform services.
Redis-based caching with TTL configuration, runtime statistics, cache inspection, and programmatic cache management.
Explore the related guides and capability pages to understand how this part of Spring Middleware fits into the broader runtime model.