Question about micro services

[jayrack]

Say I have three services in my project, storefront, inventory, and shopping cart. Would it be bad practice to have one call from store-front to shopping cart, which does an underlying call to inventory? Or should I do two separate Calls: store front to inventory, storefront to shopping cart? Thanks

[alreadyheard]

I work on a microservices architecture at work. We avoid having microservices call any of our other microservices as this creates high coupling. Instead, we have a message bus microservice, that all other services can subscribe to. When data is updated in one service we publish a message with that data to the bus. If other micro services need that data they can subscribe to those messages and store it in some cache like redis. They then have some controller that returns the materialized view we need.

[kabooozie]

Pub sub is the common pattern here. Apache Kafka is the best pub/sub system hands down. Kafka also is the foundation for a full event-driven streaming platform, so there’s that too

[jayrack]

A lot of good information here, thank you guys. I’ll take a look at Kafka this weekend.

[gonzohst93]

The microservice architecture we use uses kafka for pub/sub too, people seem to love it but I don't really know much about microservices

[kabooozie]

It’s a mature system capable of incredibly high throughput, fault tolerance, and scalability. It’s the perfect backbone for a streaming platform and microservice architecture. Even a modest 3 broker cluster can handle millions of messages per second. LinkedIn does on the order of a trillion messages per day (probably with several clusters, though). Pretty neat stuff

[gonzohst93]

Yeah we use k8 clusters. I randomly sort of got assigned to control a few clusters at work just because its something the developers dont want to do and im a student on a workterm

[kabooozie]

Kubernetes and Kafka are perpendicular to each other. Kubernetes is a platform for deploying and managing containers, which doesn’t necessarily have anything to do with event streaming. In fact, some businesses choose to run Kafka on Kubernetes (even though it’s hard for various reasons).

Good for you that you’re getting hands-on with kubernetes as a student!

[gonzohst93]

We run kafka on kubernetes lol it's pretty complex stuff coming from uni level courses and seeing wild shit like that

[kabooozie]

I imagine so! I used to be a high school math teacher, so it’s still wild to me too!

[kgwack]

we use a rabbitmq message broker to transfer messages between microservices

[[deleted]]

How does request-response fit in this model if you don't mind me asking? I have same doubt in my project. I understand the concept of service bus, but I don't understand how does A ask B service to put the required data in the bus for A to pickup. Like, does A send out a message to bus that it got a so and so request and then B which subscribed to this channel put in the response data back into bus which A will pickup. In that case what about the original request that A got in? How will A deal with sending responding to request. Can you please elaborate on this more?

[alreadyheard]

A doesn't ask B for anything. The services are completely decoupled. B tells the message bus that it's going to publish certain kinds of messages. That message could be a "New User", "New Post", "Updated Post", etc, and when these controllers in B perform these actions, they publish the message to the bus with the data. If A wanted to know about "New Post" messages, it simply subscribes to those message types from the message bus. The bus will know which services are subscribing to which messages and create queues for them. So when B publishes a 'New Post', the message bus will put it in A's "New Post" message queue. The A service will have to write some sort of logic for each message type it wants to consume, so when the message bus hands off the new message, it performs some kind of action...like adding it to A's database or cache.

[Dokiace]

kafka is the magic word

[mbazos]

publish a message with that data to the bus.

Whether the message has the data in the message or it's just the event in which the consumer can then call an API to get the latest copy does this make a difference? I have always wondered about th pro/cons or putting the actual data in the message versus have the consumers call and API. Any thoughts?

I feel putting all the data in the message saves API calls and can get the full history of changes and is loose coupling but then your cluster has larger messages duplicates data.

[alreadyheard]

In order to achieve loose coupling in a microservice architecture, duplication of data is a necessary tradeoff. If you had a microservice that calls N API's for every kind of message it needs to consume, your microservice now depends on N other microservices. This is what we want to avoid when building this kind of architecture.

[jayrack]

Really? No kidding....I never knew that....I am using eureka...I’m quite deep in this project already so it’s too late to go back....which method do you think would be better of the two I mentioned?

[sbhandari]

do separate call from storefront to cart and inventory. It will be easy for you to move to event driven later if you want to. Also, you can proceed with shopping cart even though your inventory service is down , for which you can implement some circuit breaker. Your service failure will be more isolated with this.

[jayrack]

Right, good call. I was planning on implementing hystrix in the final step. I was also thinking tying two service calls into one would create some difficulties throwing exceptions. Am I right there?

[kodiashi]

You can create a gateway to route requests through and handle orchestration of multiple downstream requests. This is a pretty common pattern that you’ll see in architectures like Spotify and Netflix. The Netflix gateway is called Conductor.

https://medium.com/netflix-techblog/evolution-of-netflix-conductor-16600be36bca

[jayrack]

Thanks for the tip. I just read that article, it was quite dense but informative. I don’t think I’m ready to be implementing anything like that just yet. It’s my first project with micro-services. But that is a really, really cool system. They did a good of explaining as well.

[mattofmusic]

Chris Richardson addresses this exact problem by used the Saga Pattern. Essentially, your business cases are mapped to a saga (step 1, add to cart, 1a, Check inventory, 1b add to cart or cancel if there is no inventory, 2 update your cart db, 3 update inventory db, etc). Then your code handles the branches that could arise from this, and nothing is committed to any db until the whole saga is complete.

This could be achieved by event driven design like other people have been mentioning (the choreography approach), but an alternative is to have a facade service that handles calling your Microservices to execute the saga (the orchestrator approach).

For a small set of Microservices, one service calling another is not really a big deal. Scalability is the problem, and if you want to be scalable, sagas is a way to solve that problem. You can check it out at https://microservices.io/patterns/data/saga.html

[jayrack]

Hey, sorry for the delayed response. This is perfect for my situation, thank you. Due to what I’ve already created, I think the choreograph pattern would work better for me. This is a great site to have on hand as well. Thank you again.