DEV Community

Cover image for Project Overview: the Basic Microservices Architecture with Spring Cloud
Bruno Drugowick
Bruno Drugowick

Posted on • Updated on • Originally published at

Project Overview: the Basic Microservices Architecture with Spring Cloud

This post presents the basic architecture of an online flower shop in a microservices architecture. I have no intention to provide detailed information on each component on this post.

I do provide a working example of a microservices application based on Spring Cloud project. I also provide a basic explanation of the components' responsibilities and how they achieve that, which I believe is a good way to understand the microservices architecture.


Store Front

storefront folder on the repository.

  • The Store itself, like a website (although here it's just an API) where a user buys flowers and stuff.
  • Balances the requests to suppliers and carriers locally (client-side load-balancing) by fetching and caching Eureka server information (ribbon).
  • Uses Hystrix to control timeout on methods that use other microservices.
  • Uses Bulkhead (from Hystrix) to separate a group of threads for each operation managed by Hystrix.
  • Controls the integration with other microservices (using states).
    • RECEIVED: order created on the storefront microservice.
    • SUPPLIER_ORDER_CREATED: order incremented with information from the supplier microservice.
    • CARRIER_VOUCHER_CREATED: order incremented with information from the carrier microservice.
  • Integrates with the authentication server.
  • Forwards authentication headers to other microservices with a RequestInterceptor bean.


supplier folder on the repository.

  • Someone who provides products on different locations.
  • Provides Orders to the storefront component.
  • Integrates with the authentication server.


carrier folder on the repository.

  • Someone who delivers stuff to clients from the suppliers.
  • Provides Vouchers to the storefront component.
  • Integrates with the authentication server.

Authentication Server

auth-service folder on the repository.

  • This is an OAuth server tying together Spring Security and Spring Cloud OAuth2.
  • Spring Security configures a user (hardcoded =).
  • Spring Cloud OAuth2 configures a client of the authorization server, the storefront (hardcoded =).

API Gateway

zuul-api-gateway folder on the repository.

  • Clients make requests for the API Gateway, which then redirects to the correct microservice for the request.
  • Implemented with Netflix Zuul.
  • Integrates (automatically) with Eureka to get microservices instances.
  • Does client-side load balancing with Ribbon automatically.

Eureka server

eureka-server folder.

  • Handles service registry and discovery.
  • Every component registers itself here.
  • Balancing is on the client, via a RestTemplate bean configured to use Eureka server as a client (this was replaced by the FeignClient. See older commits to understand how to configure a RestTemplate to work with Eureka Client).
  • Balancing is on the client through FeignClient, which is auto-configured on each application to balance requests when eureka client is being used.

Config Server

config-server folder.

  • Provides configuration to the microservices. The config-repo folder is used to store the configuration files.

Other Stuff

  • I've configured to log to papertrail (a log aggregator as a service) and used Spring Cloud Sleuth to add a traceId to every user request, being able to trace the request across microservices.
  • The logback.xml on each "domain" microservice does the magic. This will stop working after a while, so provide your own configuration for logback...


  1. Clone/fork this GitHub repository.
  2. Import everything on STS.
  3. Provide the following configurations:
    • configure the config-server application.yml file with at least the search-locations property. You may change to the location of your own config repo on your local machine or use the commented configuration to use a github repository.
    • provide a MariaDB instance running with the following schemas already created: supplier; storefront;
    • Note: you can configure the database, connection info and schema name on the configuration files on the config-server.
  4. Run each of them separately using ./mvnw spring-boot:run on each folder OR the Boot Dashboard on STS.

Test Stuff

There's a cartRequests.jmx to be imported on JMeter and test Hystrix. Ask me if you want to know more about it.

There's also a insomnia_requests.json file to be imported on Insomnia and test all endpoints.


Top comments (2)

viniciuslovato profile image
Vinicius Lovato

Great article! You should also check resilience4j as a fault tolerance library instead of hystrix. (Hystrix is deprecated and is currently is maintenance mode.

brunodrugowick profile image
Bruno Drugowick

Just added an issue to the repository:

Will do it, for sure! Thanks, Vini!