Eureka Eureka is a REST (Representational State Transfer) based service used for locating services for the purpose of load balancing and failover of middle-tier servers. We have eureka client and server. The server holds the information regarding the service instances, while the client interacts with the server and act as a round robin load balancer.… Continue reading Eureka and Feign
Debezium – Transaction log miner
In the previous post the services used eventuate to communicate. But how did it know to create events? How does the CDC module work? Well behind the scenes it is mining the transaction logs and create events from it. Enter Debezium. It's build on top of Kafka and records the changes made to the database in… Continue reading Debezium – Transaction log miner
Eventuate
Eventuate is a framework that makes event-driven microservices easy. It simplifies a lot our work, as it has change data capture(CDC), message broker(Kafka) and a event store (Eventuate). For more information regarding eventuate you can start with this. Now let's apply this on our known use case(items and bids). First of all, a picture will… Continue reading Eventuate
Junit Theories
Theories are less known components of Junit, but lately I used them and thus decided to write about them. They come in handy when you have a situation when you need to test a behavior with multiple input values. Instead of writing tests for each situation you can specify a set of inputs and apply… Continue reading Junit Theories
Deployment strategies
In the last posts we saw how to build microservices. Now it's time to deploy them. As you expect there are some strategies here as well. Multiple Service Instances per Host Pattern It can be a physical host or a virtual one. The services may live in their own JVM process, or they can share… Continue reading Deployment strategies
Communication between microservices
There are different strategies here, depending of situation. The most common style of communication is Remote Procedure Invocation (RPI). This includes REST calls, gRPC or thrift. It can be used only when one service calls another. This is known also as request/response. These are synchronous, the response must come in a timely fashion in order to… Continue reading Communication between microservices
Service discovery
The purpose of service discovery is like the name states to make the microservices discoverable. Their network locations should be dynamically assigned, as they could fail, become unresponsive and another instance should be there to perform the required work. These microservices should be highly-available.(CAP theorem). We need a service registry where the services should be… Continue reading Service discovery
Event-driven microservices
In my previous post, I wrote about different strategies for managing data when using microservices. It's obvious that the only solution is to go with database per service. But as already explained this comes higher complexity. Since we lost ACID, we will go with BASE (eventually consistent). Events will do the trick. If you worked… Continue reading Event-driven microservices
Micro-service data management
In the micro-services world, some rules must be respected: Services must be loosely coupled so that they can be developed, deployed and scaled independently Business transactions span across multiple services; they used data owned by multiple services Queries must aggregate data owned by multiple services. Different services may have different data storage requirements. In one of… Continue reading Micro-service data management
CAP Theorem
Eric Brewer, states that it is impossible for a distributed computer system to simultaneously provide more than two out of three of the following guarantees: ConsistencyAvailabilityPartition Tolerance Consistency means that all members of the system will see the same data at the same time. A read is guaranteed to return the most recent write or… Continue reading CAP Theorem
Learn. Write. Repeat. 