1

enter image description here

I read theory but I need practical architectural advice on the actual implementation in java language for microservices. In the context of the attached screenshot. Here is my setup.

Order Project consisting of the following 4 Modules.

  1. Order History (Jar file, Docker Container)
  2. Order Placement (Jar file, Docker Container)
  3. Order Tracking (Jar file, Docker Container)
  4. Order Dispute (Jar file, Docker Container)
  5. Service (WAR file, Docker Container)

Service (5) sits on the front (order.example.com), receives HTTP request, then calls 1 or 2 or 3 or 4 (depending upon the URI) via gRPC and returns the result to the client.

Q1. Is 1, 2, 3, 4 above considered a Microservice or is OrderManagement or ShoppingCart a microservice?

Q2. Shopping Cart has the same setup as Order (sits behind cart.example.com). Communicate between Order and Shopping Cart via like Messaging (Kafka)?

Is this correct? Hopefully, I don't have a nano anti-pattern here?

Improve this question

2 Answers 2

Reset to default
1

A lot depends on the details, but in general I would try to avoid having synchronous dependencies if I have full control over the design.

For example if you already know that the service will need to chain-call to downstream services, why not try to design the system in a way that whatever information is needed is at the node where the request comes in.

In other words, I would try to make every service as autonomous as possible, ideally not requiring any request-response dependencies at all. This would help you to evolve/update/operate each service independently.

Q1: Since there is no generally accepted definition of a "microservice", it's up to you what you call them.

Q2: Depends. As I said, you should try to avoid request-response communication. If you can't, "messaging" might not be the best approach. Since you need the response also, and the request does not make sense without the response, you don't really need persistent messages. If you have stateless services you don't need Kafka partitions, groups or similar things. Basically, you should only introduce Kafka if you know a specific feature you want to exploit. If a HTTP call is sufficient, then prefer that.

Improve this answer
10
  • I'm a bit confused, when you say whatever information is needed is at the node where the request comes in will it not become a monolith with OrderManagement including all the code for it's 4 submodules (History, Placement, Tracking, Dispute) for instance.
    – AppDeveloper
    Aug 2, 2019 at 6:02
  • avoid request-response communication. If you can't, "messaging" might not be the best approach, I assume you are referring to REST when you say request-response, so if not request-response, not messaging then what else?
    – AppDeveloper
    Aug 2, 2019 at 6:04
  • Usually (and again, the disclaimer that I don't know the details of your system) you can find a way to cleanly separate parts. If you can't, distributing your application will only result in a distributed monolith. With request-response I don't mean REST, I mean any communication in which you have to wait for the answer to complete some function. Even if you use Kafka, if you have to wait for a response to complete your response to the client, that is a request-response protocol.
    – Robert Bräutigam
    Aug 2, 2019 at 9:11
  • So, you should avoid request-response, because that is basically a circular dependency then. If you managed to do that, the hard part is done. You are left with either no communication at all, or some form of fire-and-forget type, or push-type, etc. Those are good candidates for messaging, because those usually are persistent things.
    – Robert Bräutigam
    Aug 2, 2019 at 9:14
  • I see what you mean, this is good stuff, you are basically saying to design systems in such a way that one service doesn't have to wait for the response, it sends off the request, in a way delegate to the other service and continue with the next request. , fire-forget type or push type, cool.
    – AppDeveloper
    Aug 3, 2019 at 7:01
0

Your Architecture looks good. You have seperated the concerns and have a good grasp of the domain you are working in.

Q1 Order Management and Shopping Cart are the Customer facing parts of your application or the business-relevant aggregation of your services 1-4.

Q2 Communication via messaging is a reasonable choice - but not the only one you have. You could, for example, also talk directly to the services via REST (or other means).

Improve this answer
5
  • Thanks. I also need confirmation on the Service (WAR) part that sits on it's on docker container. Service 1-4 are just Jar's and have their own isolatd docker containers as well. Service (5) calls 1-4 via gRPC. Total 5 modules, is it ok?
    – AppDeveloper
    Aug 1, 2019 at 12:33
  • It should be fine. Would one module more or less matter? With what constraints are you dealing?
    – mhr
    Aug 1, 2019 at 12:43
  • oh no problem, I can add more modules, no constraints. what's the idea? Feel free to add please
    – AppDeveloper
    Aug 1, 2019 at 12:44
  • Do you have a specific word for this Customer facing part -> Service (5), call it API gateway, API endpoint? what's the actual term for this?
    – AppDeveloper
    Aug 1, 2019 at 12:56
  • for service registry/discovery, I'm also thinking to put consul there, have both order and cart register themselves to consul. Then either order or cart wish to call the other, they'd get the endpoint from consul and make a request.
    – AppDeveloper
    Aug 1, 2019 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.