Microservices Architecture (First Timer)

[LAazsx]

Hi friends,

 

This is my first attempt in designing a microservices architecture. Please be kind 

 

Scenario:

1. The client would want a system to monitor the inventory and give alerts when stock levels reach a certain level.

2. The company has multiple warehouses/branches. Stocks will be transferred between them.

3. Handle purchase requisitions, purchase orders, and the routing of each.

 

Hoping for your feedback from you awesome peeps!  

 

[DevBlox]

Pretty good attempt, it's nice that you've kept a flat layout. I wouldn't be confident about some databases/apis (those are db/api combos right?) that both produce and consume event bus messages. Consumers and Producers are better off as separate services (it wouldn't really make sense if they're consuming their own messages and performing api duties), leaving databases with pure api services. That's as much as I can infer from the picture, since there is no other info on what data is written where. Knowing that might uncover some issues.

[LAazsx]

8 minutes ago, DevBlox said:

 Consumers and Producers are better off as separate services (it wouldn't really make sense if they're consuming their own messages and performing api duties), leaving databases with pure api services. 

I'm guessing you're pertaining to Procurement Workflow, Inventory Manager, and Stock Transfer Manager.

 

Using Stock Transfer Manager as an example.

 

If I understand correctly, it should be broken out into smaller components -  Manager [Logic] (no db), Inventory Transaction Log (db), and Inventory Monitor. Is this correct?

 

 

Quote

it's nice that you've kept a flat layout

what do you mean by "flat layout"?

 

 

Thanks for helping me out!

[DevBlox]

33 minutes ago, LAazsx said:

If I understand correctly, it should be broken out into smaller components -  Manager [Logic] (no db), Inventory Transaction Log (db), and Inventory Monitor. Is this correct?

Maybe just one more service. I'd maybe do it like so:

• Transaction Log API - just an api that pulls things from the database on request.
• Transaction Consumer (or well, Monitor) - consumes the messages in the bus, and puts them in the Transaction Log DB. It could also then produce some other event for another service that a certain message is already processed and in database. Letting the push notification service to know for example, so it, in it's own right, would see that and, would let the user know that processing is complete.
• No separate Producer. The Webapp and API (and whatever else ever needs to produce them) would produce the events to the event bus directly for the Consumer to process and put into the DB.

This way if the API is down, messages are still being produced and consumed, still get written to database. Same if the consumer is down, you can still read the database even though it is not updated at the moment. If they would be all one service and it would be down, you're in trouble. It's unlikely that the event bus will be down, usually it's a large distributed service, plenty of failover.

 

33 minutes ago, LAazsx said:

what do you mean by "flat layout"?

By flat I mean the Webapp and API gateway are no more than 1 hop away from where the actual data they're requesting is (ignoring the connection between the database and it's api), that's good, it would definitely be pretty snappy. You want to avoid dependency hell in micro-services, that causes a lot of latency and sluggish operation. Having 2 hops would be ok with some services, but that would already be significantly slower, because that middle service would probably be calling another 2 or 3 to complete it's own response. Might be acceptable for some services, but not others.

 

EDIT: Should mention that the layout i suggest means the user should not expect an immediate response with the result from that service. If the Webapp is only producing the message, it will be processed eventually. Might be less than a second, might be minutes or hours in a serious downtime. If you want an immediate response, the situation would probably be a little different.

[LAazsx]

13 minutes ago, DevBlox said:

Maybe just one more service. I'd maybe do it like so:

• Transaction Log API - just an api that pulls things from the database on request.
• Transaction Consumer (or well, Monitor) - consumes the messages in the bus, and puts them in the Transaction Log DB. It could also then produce some other event for another service that a certain message is already processed and in database. For example a push notification service.
• No separate Producer. The Webapp and API (and whatever else ever needs to produce them) would produce the events to the event bus directly for the Consumer to process and put into the DB.

This way if the API is down, messages are still being produced and consumed, still get written to database. Same if the consumer is down, you can still read the database even though it is not updated at the moment. If they would be all one service and it would be down, you're in trouble. It's unlikely that the event bus will be down, usually it's a large distributed service, plenty of failover.

 

Good point. I've revised the diagram.

 

 

 

Since Procurement contains Purchase Requisition and Purchase Order, will each require it's own logging and consumer/producer services? 

[DevBlox]

5 hours ago, LAazsx said:

Since Procurement contains Purchase Requisition and Purchase Order, will each require it's own logging and consumer/producer services? 

They might, it really depends on what you want to do with them. There's just really no need to make producers if other services can just write to the bus directly, one less part to fail that basically just receives a request, and pushes to the bus - that's basically nothing. As for logging, that doesn't need to be scattered, it would just be a pain to work with. I'd just set up an Elasticsearch cluster of whatever size I need, and centralise logs there.

 

I remembered a nice talk about all of this, might be interesting to you. It's specifically Go related, but has some nice displays of how microservices can work.

 

[LAazsx]

Thanks for the feedback DevBlox! Watching the vid now.

[Anishacorn]

Oh, I've been doing this type of work for a very long time. I advise you to read books about Microservices Architecture. I think you will learn a lot. Of course, I don't understand one thing, why did you take a job from a client that you don't know how to do? For example, I've modernized applications at my business, but I hired cloud computing specialists who were paid to do this.

[SydneyBrokeIt]

It's a tool like any other.

[MisterWhite]

The usual suggestion is to go with a well managed monolith first and only then break it apart if needed into multiple services. Have some sort of bus that bridges dependencies or calling other "services". Start with monolith, but keep microservices principle basically. Try searching for info about "Loosely Coupled Monolith" or "Modular monolith"

 

P.S. microservices are not always the answer. They don't solve all of your problems but for sure introduce more. A whole team should be responsible for that many services

 

P.P.S Only now noticed it is a question from 2019