ArchGen

Spring PetClinic Microservices Architecture

Focus: API Gateway + Eureka + Config Server + Domain Services + Observability. Key areas: Spring MVC / Thymeleaf (optional UI), React (optional), HTTP/JSON.

Use this as a block diagram of the system when explaining architecture.

Preview
Edit this example
Diagram caption: Spring PetClinic Microservices Architecture (API Gateway + Eureka + Config Server + Domain Services + Observability) has 5 layers: Client & Edge Layer, Platform Services Layer, Domain Microservices Layer, Data Layer (Schema per Service), Observability & Resilience Layer.

Prompt

Microservices architecture diagram based on the Spring PetClinic reference implementation. The design should feature an API Gateway acting as the entry point, connected to a Service Discovery Server (Eureka) and a Centralized Config Server backed by Git. Break down the backend into distinct domain services: Customers Service, Vets Service, and Visits Service, each owning its separate database schema. Include the Tracing infrastructure (Zipkin/Sleuth) and Circuit Breaker Dashboard (Hystrix/Resilience4j) for observability.
Highlights
  • Layer details · Client & Edge Layer: Modules include Web UI / Client Apps, API Gateway (Entry Point).
  • Layer details · Platform Services Layer: Modules include Service Discovery Server, Centralized Config Server, Config Repository (Git Backing Store).
  • Module responsibilities · Client & Edge Layer / Web UI / Client Apps: Render PetClinic UI workflows; Call backend APIs through a single entry point; Display aggregated data from multiple services

Overview

Spring PetClinic Microservices Architecture (API Gateway + Eureka + Config Server + Domain Services + Observability) has 5 layers: Client & Edge Layer, Platform Services Layer, Domain Microservices Layer, Data Layer (Schema per Service), Observability & Resilience Layer.

Layer details

Show all (5)
  • Client & Edge Layer: Modules include Web UI / Client Apps, API Gateway (Entry Point).
  • Platform Services Layer: Modules include Service Discovery Server, Centralized Config Server, Config Repository (Git Backing Store).
  • Domain Microservices Layer: Modules include Customers Service, Vets Service, Visits Service, Inter-service Communication.
  • Data Layer (Schema per Service): Modules include Customers DB Schema, Vets DB Schema, Visits DB Schema.
  • Observability & Resilience Layer: Modules include Distributed Tracing, Circuit Breaker & Resilience Dashboard, Metrics & Logging (Optional).

Module responsibilities

Show all (15)
  • Client & Edge Layer / Web UI / Client Apps: Render PetClinic UI workflows; Call backend APIs through a single entry point; Display aggregated data from multiple services
  • Client & Edge Layer / API Gateway (Entry Point): Provide a single ingress for clients; Perform dynamic routing via service discovery; Apply cross-cutting concerns (filters)
  • Platform Services Layer / Service Discovery Server: Maintain a registry of running service instances; Enable dynamic routing and load balancing; Support resilience via instance health awareness
  • Platform Services Layer / Centralized Config Server: Serve versioned configuration to services; Centralize application properties management; Enable consistent configuration across environments
  • Platform Services Layer / Config Repository (Git Backing Store): Store configuration as code; Provide versioning and auditability; Enable safe rollbacks of config changes
  • Domain Microservices Layer / Customers Service: Own customer domain (owners and pets); Expose customer APIs to gateway and peers; Maintain its own persistence schema
  • Domain Microservices Layer / Vets Service: Own veterinarian domain data; Expose vets/specialties APIs; Maintain its own persistence schema
  • Domain Microservices Layer / Visits Service: Own visit scheduling and history domain; Coordinate cross-service reads when needed; Maintain its own persistence schema
  • Domain Microservices Layer / Inter-service Communication: Enable service-to-service requests; Apply resilience policies for calls; Propagate tracing context across hops
  • Data Layer (Schema per Service) / Customers DB Schema: Store customer domain entities; Isolate customer data ownership; Support independent service evolution
  • Data Layer (Schema per Service) / Vets DB Schema: Store vets and specialties data; Isolate vets domain ownership; Support independent scaling
  • Data Layer (Schema per Service) / Visits DB Schema: Store visit records and history; Isolate visits domain ownership; Enable independent deployments
  • Observability & Resilience Layer / Distributed Tracing: Trace requests end-to-end across services; Identify latency hotspots and failures; Enable debugging via trace correlation
  • Observability & Resilience Layer / Circuit Breaker & Resilience Dashboard: Protect services from cascading failures; Visualize resilience metrics and breaker states; Support operational troubleshooting
  • Observability & Resilience Layer / Metrics & Logging (Optional): Monitor service health and performance; Alert on errors and saturation; Support capacity planning

Key flows

Show all (3)
  • Startup and config: each domain service boots with Spring Cloud Config Server to fetch versioned properties from Git, then registers with Eureka so the API Gateway can discover instances dynamically for routing and load balancing.
  • Request flow: clients call the API Gateway, which routes to Customers/Vets/Visits services via Eureka discovery; inter-service calls (e.g., Visits validating pet existence via Customers) use Feign/REST with Resilience4j policies (timeouts/retries/circuit breakers).
  • Observability and resilience: tracing context is propagated through gateway and services via Sleuth/Micrometer Tracing and reported to Zipkin; circuit breaker metrics are exposed via Actuator/Micrometer and visualized via Hystrix Dashboard (legacy) or Resilience4j-backed dashboards.