All projects
Academic projectCompleted2026BackendCloud
A library management system built as six Spring Boot and Spring Cloud services, with service discovery, central configuration, an API gateway, JWT authentication, circuit breakers and distributed tracing. The whole stack runs locally with Docker Compose.
MSc coursework (Microservices Architecture, Technological University of the Shannon). A local Docker Compose demo, not a deployed production system.
- Six Spring Boot modules in a Maven multi-module build. Eureka discovery, Config Server, API gateway, auth service, library service and inventory service.
- The library service calls the inventory service through a load-balanced client. A circuit breaker, retries, timeouts and a fallback keep it answering when inventory is down.
- The gateway routes by service name, gives every route its own circuit breaker, and reports ready only once the services it depends on have registered.
- Email and password sign-up with BCrypt, optional Google, GitHub and Facebook login, and signed JWTs. The gateway and each service check the token themselves.
- Docker Compose runs three MySQL databases (one per service that owns data), Zipkin and two replicas of the library service, starting each container in order using health checks.
- Includes a member web UI, a smoke-test script, architecture diagrams and a security document that lists the known limitations.
The problem
The assignment was to build a cloud-native library management system that uses the standard microservice patterns:
- service discovery
- central configuration
- gateway routing
- calls between services
- resilience
- security
- distributed tracing
What was built
A Maven multi-module Spring Boot and Spring Cloud project with six services:
- discovery-server: a Eureka registry.
- config-server: Spring Cloud Config, reading YAML files from a config folder.
- gateway-service: Spring Cloud Gateway. It checks tokens, enforces roles, gives each route a circuit breaker and serves the member web UI.
- auth-service: sign-up and login with email and password, optional social login, and token issuing and renewal.
- library-service: libraries and books, search, and a book availability view that combines book data with stock levels.
- inventory-service: stock records for each branch, with reserve and return operations.
Together the services expose 28 REST endpoints.
Architecture
- Routing. Requests go through the gateway to the auth, library and inventory services, which the gateway finds through Eureka.
- Data. Each service that owns data has its own MySQL database.
- Load balancing. Two replicas of the library service register under the same name, and the gateway balances requests between them.
- Service calls. The library service calls inventory with a load-balanced web client and forwards the caller’s token.
- Tracing. Every hop is traced to Zipkin through Micrometer.
Engineering details
- Resilience. The library-to-inventory call is protected by a circuit breaker and retries, with a 1-second connect and 3-second response timeout. If inventory is unavailable, the fallback returns an “unavailable” stock status instead of an error. Gateway routes have their own circuit breakers and time limits.
- Security. Tokens are signed and carry role claims. The gateway, the library service and the inventory service each validate them, so no service simply trusts the gateway. Reads need the user role and writes need the admin role. A token can be renewed only once, in its last five minutes.
- Start-up order. Containers wait for the services they depend on to report ready. The gateway’s readiness also checks that the auth, library and inventory services have registered.
- Dependency hygiene. The parent build pins patched versions of vulnerable transitive libraries, and keeps unused libraries out of the packaged JARs.
- Tooling. A single multi-stage Dockerfile builds any module. A PowerShell script waits for the stack to settle and then smoke-tests it.
Limitations
The repository’s own security document lists the limitations, as you would expect for coursework:
- one shared signing secret kept in configuration
- tokens stored in the browser’s local storage
- no token revocation or rate limiting
- the database schema is generated automatically, with no migrations
- a small test suite
The stack is meant for local demos only.