Eureka (https://github.com/Netflix/eureka) consists of the following:

• The Eureka server:
• The Eureka server is a REST-based service. It is used for locating services for load balancing and failover middle tiers. 
• The Eureka server helps to load balance among the instances. They are more useful in a cloud-based environment where the availability is intermittent. On the other hand, traditional load balancers help in load balancing the traffic between known and fixed instances.

• The Eureka client:
• Eureka provides a Eureka client, which makes the interaction between servers seamless. It is a Java-based client.

Eureka acts as a middle-tier load balancer that helps to load balance the host of middle-tier services. They provide a simple round-robin-based load balancing by default. The load balancing algorithm can be customized as needed with a wrapper.

They cannot provide sticky sessions. They also fit perfectly for client-based load balancing scenarios (as seen earlier).

Eureka has no restriction on communication technology. We can use anything, such as Thrift, HTTP, or any RPC mechanisms, for communication.

Imagine our application is in different AWS Availability Zones. We register a Eureka cluster in each of the zones that hold information about available services in that region only and start the Eureka server in each zone to handle zone failures.

All the services will register themselves to the Eureka server and send their heartbeats. When the client no longer sends a heartbeat, the service is taken out of the registry itself and the information is passed across the Eureka nodes in the cluster. Then, any client from any zone will look up the registry information to locate it and then make any remote calls. Also, we need to ensure that Eureka clusters between regions do not communicate with each other.

Eureka prefers availability over consistency. That is when the services are connected to the Eureka server and it shares the complete configuration between the services. This enables services to run even when the Eureka server goes down. In production, we have to run Eureka in a high-availability cluster for better consistency.

Eureka also has the ability to add or remove servers on the fly. This makes it the right choice for a service registry and service discovery.