dmslob/atlas-hotel

1. System shape

This repository is a Spring-based microservice suite for a hotel domain. It is split into a control plane for configuration/discovery/routing and a business plane for guest, room, and reservation operations.

2. Control plane services

- config-server centralizes runtime configuration. Its src/main/resources/config/*.yaml files hold per-service config for guest, room, and reservation services.

- eurekaserver is the service registry used for discovery.

- gatewayserver is the edge entry point for client traffic and contains request tracing and fallback handling.

3. Request entry path

External clients are expected to hit the gateway first. The gateway applies request filtering/tracing, then routes to backend services using registry-based discovery. The presence of a FallbackController indicates it is also the failure boundary when downstream calls fail.

4. Business services

- guest-service manages guest data.

- room-service manages room data.

- reservation-service manages reservations and coordinates with the other two services.

Each service follows the same layered pattern: controller -> service -> repository -> entity, with DTOs/models for API contracts and a global exception handler for consistent error responses.

5. Reservation orchestration

reservation-service is the only service that clearly depends on other services at runtime. It uses Feign clients for guest-service and room-service, plus fallback classes for resilience. That makes reservation the orchestration point for combining guest and room information with reservation persistence.

6. Data ownership

Each domain service has its own schema.sql and data.sql, which strongly suggests service-local persistence rather than a shared database. The repositories are isolated per service, reinforcing bounded contexts:

- GuestRepository

- RoomRepository

- ReservationRepository

7. Configuration and runtime binding

Services are designed to bootstrap from the config server and register themselves in Eureka. The config server exposes service-specific YAML by application name, so runtime behavior is externalized from the codebase and can be refreshed without redeploying.

8. Resilience and failure behavior

The architecture includes explicit resilience points:

- Feign fallback implementations in reservation-service

- Gateway fallback controller

- Actuator-based refresh endpoints

- Readme references to Spring Cloud Bus refresh via RabbitMQ

This indicates the system is meant to tolerate partial downstream failures and support live config changes.

9. Observability stack

The docker-compose/observability folder includes Prometheus, Grafana, Loki, Tempo, and Alloy. That means the services expose metrics/logs/traces via Spring Boot Actuator, Prometheus scrapes metrics, and Grafana is the visualization layer. Observability is a first-class part of the runtime topology, not an afterthought.

10. Deployment model

The repo is organized for containerized local composition and image publishing. The README shows:

- Jib-based image builds per service

- Docker Hub image pushes

- docker-compose/default for bringing the stack up locally

So the main deployment unit is the individual microservice container, coordinated by compose in local environments.

11. API surface and developer access

The domain services expose Swagger UI endpoints for interactive API docs, which implies they are independently consumable APIs rather than internal-only components. The gateway and control-plane services are operational infrastructure rather than user-facing business APIs.

12. Optional external integration

The README mentions Keycloak for authN/authZ, but it is not represented as an in-repo service. Treat it as an external optional identity provider that can sit in front of the gateway or protected services.