API Design – Load Balancer or API Gateway Availability

The way that you effectively load balance a Consumer in Kafka is that you register each of your client nodes/processes into a single Consumer Group.

Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group. Consumer instances can be in separate processes or on separate machines.

If all the consumer instances have the same consumer group, then the records will effectively be load balanced over the consumer instances.

If all the consumer instances have different consumer groups, then each record will be broadcast to all the consumer processes.

[Source] https://kafka.apache.org/intro

This is rather basic Client configuration. There is no concept of a "Message Queue" in Kafka, however you can reliably handle transaction based message driven events in this way.

People often hear "micro-service" and think "nano-service", and this can cause some confusion. These are micro-services, so you don't need a separate service for every single entity. Everything you are trying to do should be in the booking and notification services. You don't need the driver service (for any of the activity you described).

Getting a list of drivers available to book falls under the booking service. A common pitfall is to not group related activities into the same service, this is called low-coherence, and it is very bad. Remember, you group things into a service by problem domain, not by entity.

Now, as for reuse, the advantage of having a separate micro-service is, now you can have three separate teams making the consumer facing apps. One team for the standard html web app, an android app, and an ios app. All these different applications can be built completely differently, and look appropriate for their particular platform (without repeating code). The booking service code is reused by all three of these apps, because all three apps make http calls to the service instead having their own booking code.

A typical booking flow would look like this:

1. The android app calls the booking service to get a list of available drivers
2. The booking service returns a list of drivers to the app
3. The user then selects their driver and the app calls the "book" method of the booking service
4. The booking service service calls the notification service with the booking details
5. The notification service sends a notification to the driver, notifying him of the booking
6. The driver app sends a message to the notification service when they are within a mile of the customer
7. The notification service sends the alert to the customer that their driver is almost there

Hope this helped; remember, they are micro-services, not nano-services, don't try to divide the same problem domain. So, to answer the title of your question, when you keep a micro-service the proper size, all, or most of, the business logic for that problem domain can live within that micro-service.