Skip to main content
The SGIVU platform consists of multiple microservices, each with its own configuration managed through Spring Cloud Config. This page provides an overview of all services and common configuration patterns.

​
Service Architecture

Auth Service

OAuth2/OIDC authorization server on port 9000

Gateway Service

API Gateway with session management on port 8080

Discovery Service

Eureka service registry on port 8761

User Service

User management microservice on port 8081

Client Service

Client management microservice on port 8082

Vehicle Service

Vehicle catalog with S3 integration on port 8083

Purchase-Sale Service

Transaction orchestration service on port 8084

​
Service Port Allocation

ServicePortPurposeDatabase
sgivu-auth9000OAuth2 Authorization ServerPostgreSQL
sgivu-gateway8080API Gateway & Session ManagementRedis
sgivu-discovery8761Eureka Service RegistryNone
sgivu-user8081User ManagementPostgreSQL
sgivu-client8082Client ManagementPostgreSQL
sgivu-vehicle8083Vehicle Catalog & AWS S3PostgreSQL
sgivu-purchase-sale8084Transaction OrchestrationPostgreSQL

​
Common Configuration Patterns

​
Eureka Service Discovery

Most services register with Eureka for service discovery: 
eureka:
  instance:
    instance-id: ${spring.cloud.client.hostname}:${spring.application.name}:${random.value}
  client:
    service-url:
      defaultZone: ${EUREKA_URL:http://sgivu-discovery:8761/eureka}
The instance-id includes a random value to support multiple instances of the same service.

​
Database Configuration

All data services use PostgreSQL with Flyway migrations: 
spring:
  datasource:
    url: jdbc:postgresql://${DEV_*_DB_HOST:host.docker.internal}:${DEV_*_DB_PORT:5432}/${DEV_*_DB_NAME}
    username: ${DEV_*_DB_USERNAME}
    password: ${DEV_*_DB_PASSWORD}
  jpa:
    hibernate:
      ddl-auto: validate
    show-sql: true
  flyway:
    baseline-on-migrate: true
    clean-disabled: false
Production environments have clean-disabled: true to prevent accidental database deletion.

​
Service-to-Service Authentication

All microservices use a shared secret for internal API calls: 
service:
  internal:
    secret-key: "${SERVICE_INTERNAL_SECRET_KEY}"
This secret must be the same across all services to enable secure service-to-service communication.

​
Distributed Tracing

All services integrate with Zipkin for distributed tracing: 
management:
  tracing:
    sampling:
      probability: 0.1  # Sample 10% of requests
  zipkin:
    tracing:
      endpoint: http://sgivu-zipkin:9411/api/v2/spans

​
Service Registry Pattern

Services maintain a map of other services they depend on: 
services:
  map:
    sgivu-auth:
      name: sgivu-auth
      url: ${SGIVU_AUTH_URL:http://sgivu-auth:9000}

​
Actuator Endpoints

management:
  endpoints:
    web:
      exposure:
        include: "*"  # All endpoints exposed
  endpoint:
    health:
      show-details: always

​
OpenAPI Documentation

Each service exposes its API documentation through the gateway: 
springdoc:
  swagger-ui:
    url: /docs/{service-name}/v3/api-docs
    configUrl: /docs/{service-name}/v3/api-docs/swagger-config

​
Environment Variables

​
Common to All Services

  • SERVICE_INTERNAL_SECRET_KEY - Shared secret for service-to-service authentication
  • EUREKA_URL - Eureka server URL (default: http://sgivu-discovery:8761/eureka)
  • PORT - Service port (overrides default)

​
Profile-Specific

Each service requires database credentials for its profile: Development:
  • DEV_{SERVICE}_DB_HOST
  • DEV_{SERVICE}_DB_PORT
  • DEV_{SERVICE}_DB_NAME
  • DEV_{SERVICE}_DB_USERNAME
  • DEV_{SERVICE}_DB_PASSWORD
Production:
  • PROD_{SERVICE}_DB_HOST
  • PROD_{SERVICE}_DB_PORT
  • PROD_{SERVICE}_DB_NAME
  • PROD_{SERVICE}_DB_USERNAME
  • PROD_{SERVICE}_DB_PASSWORD

​
Configuration Layering

Spring Cloud Config uses a three-tier configuration strategy:
  1. Base configuration ({service-name}.yml) - Common settings across all environments
  2. Profile configuration ({service-name}-{profile}.yml) - Environment-specific overrides
  3. Environment variables - Runtime overrides
Spring Boot resolves configuration in this order (higher priority wins):
  1. Environment variables
  2. Profile-specific YAML (-dev, -prod)
  3. Base YAML file
  4. Application defaults
This allows you to set defaults in the base config and override them per environment.

​
Service Dependencies

​
Next Steps

Auth Service

Configure OAuth2 authorization

Gateway Service

Set up API gateway and routing

Discovery Service

Configure service registry

Business Services

Configure microservices

Build docs developers (and LLMs) love

Get started for freeTalk to us