For a while now we have started to hear about concepts like microservices architecture, some sort of version 2.0 of a distributed architecture. This type of architecture has been spurred on by the great boom in Cloud technologies, which fit perfectly with it.

In this article (divided into two posts, you can access the second part by clicking here) we try to identify who are the ‘’new kids in town’’ in this architecture and what part they play in it.

Most of the components of the architecture were originally developed by Netflix, the well-known online streaming site, which has the largest network downloading traffic in all of the USA (often representing a third of the total traffic). Netflix’s architecture is made up of more than 500 microservices and has more than 50 million subscriptions that make some 2,000 million requests every day.

Below we analyze a selection of the most important components of the previously mentioned architecture from three different angles, ‘What is it?’, ‘How does it work?’ and “What does it provide?”.


What is it? Eureka is a server for the registration and location of microservices, load balancing and fault tolerance. Eureka’s job is to register the different instances of existing microservices, their location, condition, metadata…

How does it work? Each microservice will communicate with the Eureka server while starting, in order to notify that it’s available, where it’s located, its metadata…. In this way Eureka will keep the information of all the ecosystem microservices in its register. The new microservice will continue notifying Eureka of its condition every 30 seconds, which we refer to as ‘heartbeats’. If after 3 periods Eureka still hasn't received a notification from this microservice it will be eliminated from the register. Likewise once Eureka receives three notifications it will consider the service available once again.

Each client of Eureka can also recover the register in order to locate other microservices with which it needs to communicate. The register’s information is stored in the client’s cache. Eureka can be configured to work in cluster mode where various ‘’peer’’ instances will interchange their information. This, together with the register’s information stored in the client’s cache gives Eureka a high fault tolerance.

What does it provide?


What is it? Cloud-­config is a configuration server thought for distributed systems. Its job is to store the ecostystem’s microservices configuration properties.

How does it work? Cloud-config stores configuration properties in a git by default. While starting, a microservice will consult the associated properties to the cloud­-config server which will download them from the git repository. The whole process is carried out transparently without a single code line.

The property files will traditionally be named with the format {microservice}–{profile}.{yml|properties} where ‘microservice’ is the identifier of the said microservice and ‘profile’ a Spring profile.

What does it provide?

Tell us what you think.

Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.


We are committed.

Technology, people and positive impact.