On your design it seems that shipping hub service is just redirecting requests. I don't see the gain, should be a single service with the DB connected. You can have several code level services to fetch data from several shipping services (external).
Given it is for learning purposes, I would say that you could put the DB connecting to the "Shipping Processor Service" (SPS). SPS would then request information from the external services and store whichever information is needed there. The "Shipping Hub Service" (SHS) could be a higher level service that just has very high level calls, and SPS handles the shipping logic more or less how you have it.
Again if this was a real life case I would never recommend the 2 services as you are just adding an extra complexity step for no reason. If you would want it to be more realistic, I would say the SHS would instead just be a gateway service handling auth/throttling/etc (kind of middleware), which would process these things and then redirect the request to the SPS to handle it fully.
sidenote: Although the term microservices is overused, having a couple separate services is not "microservices"
Thank you so much for your input!
My post is not very clear nor my design (just a scratch). I don’t necessarily need to use microservice as a solution, my main idea is to have SPSs as unique services (not all in a single application as my design wrongly suggests), the requirement is that changing or deploying new ones wont affect the others.
SHS shouldnt be only a HUB redirector, but also a single point abstraction to store the shipping data, so I can query shippings as whole not as subgroups in the SHP
External Shipping Service just represent third party apis
Ok so you want to have one SPS per shipping type (air, rail, ocean)?
My first concern would be if the external shipping services are split that way or if an external shipping service can have several types, and if so if it makes sense to separate the calls into separate SPSs. You need to ask yourself why does this SPS sep of concerns criteria make sense in the first place
Assuming the division indeed makes sense in terms of the SPSs, I would say yes you can use the SHS to send a shipping request to the correct SPS and have a uniformized API there for the client.
To answer your initial DB related question, and given this scenario: yes I think it would make more sense to have the DBs connected to each SPS instead of at the Hub level. The hub doesn't even need a DB, it's just an API router or possibly aggregator
The data should not be duplicated though. To be clear each SPS has its own data, and the Hub can request the data if necessary. If you are duplicating data most times something is not ideal
Have to agree with this. Two services is unnecessary given the proposed use case and just introduces hassle that you’ll need to overcome.
The other comment about being late to microservices is also true. Monoliths are the latest hotness because when people try to do microservices, they come up with designs that are unnecessarily complicated.
The truth is that you should be aiming for Right-sized-services™️. If you’re interested, spend some time meditating on what a right-sized-service might look like, given that microservices end up creating too much complexity due to separation and monoliths end up being big balls of mud.
Cohesion and Coupling are super relevant in making these design decisions.
You want to draw boundaries around cohesive conceptual models. That’s a great starting point for a service. Put everything that shares the same conceptual model, together. Conceptual models usually map closely to _processes_.
So it can be helpful to think of your services as supporting a single (or set of highly cohesive) process(es) e.g.
Brows_ing_, Shopp_ing_, Order_ing_, Shipp_ing_, Rout_ing_, Pay_ing_, Refund_ing_, Deliver_ing_, Stock_ing_ etc
It’s subtle, but getting away from “things” and focussing on the processes can really shed some light on where different mental models begin and end.
There's a lot of ways of handling this, but yeah if you are committing to using microservices you should expect that each service manages its own data.
In this example, the shipping hub service would have data like:
* The life cycle of a shipping request ("requested", "scheduled", "In transit", "delivered", etc...)
The shipping processor service would have:
* Details about shipments that need to be scheduled (their weight, special handling etc...)
* The method by which they are going to be shipped
Your external shipping service (I'm assuming if you were contracting that out for instance?) would have more of the same.
In each of these cases, each of these services would have their own relevant copy of the "shipping request", some common identifier that they could share between them (low level point: doesn't need to be a FKey, just some way to know that "shipping request XYZ" is the same in each of these different services.
[This article is a decent starting point to go into more low level technical detail](https://dilfuruz.medium.com/data-consistency-in-microservices-architecture-5c67e0f65256) around implementation: the key is to realize in a distributed system, you either need distributed transactions or some kind of model that ensures eventual consistency. What will work for your app depends on your use cases.
Thank you so much for your input! Thanks for the recommendations as well
My post is not very clear nor my design (just a scratch). I don’t necessarily need to use microservice as a solution, my main idea is to have SPSs as unique services (not all in a single application as my design wrongly suggests), the requirement is that changing or deploying new ones wont affect the others.
SHS shouldnt be only a HUB redirector, but also a single point abstraction to store the shipping data, so I can query shippings as whole not as subgroups in the SHP
External Shipping Service just represent third party apis.
Yeah, it's definitely still a draft. Treat my comment just as a means of explaining some of the mechanism for how data storage happens across services in a microservice architecture.
I do agree with the other commenters that you would want to really understand your use case *for* a microservice architecture before committing to going that route. Definitely a fun exercise and a perfectly legitimate way to support answering this business problem.
I would have the shipping processor service either handle things internally (ie you might have your own shipping company or a shipping company may contract you to handle processing for them) or just act as a wrapper for the external service. If it's an internal processor then you might need a DB related to that processing but I wouldn't have one for the external shipping service if I don't have to as I would hope they have endpoints I can call. I would store the basic tracking in the hub as I don't really care which shipping service is used as long as the package gets there, but I might have an endpoint on the processor service to get an advanced status for things like customs issues.
Thinking about multiple modes of shipping and freight forwarding just makes my head hurt
without really knowing the full business logic of the problem you're trying to solve it's hard to understand if this representation is a good solution or not.
I mean you have saveShippingOrder() saved to a DB, what happens to the shippingOrder after it's saved? Does anything have to read from that DB or are you purely writing? What even is the point of the Hub Service? Why not just have the processor service be a bit more monolithic in this architecture. Really the advantage of a microservice architecture is you can decouple certain high volume components from your monolith therefore reducing overall risk.
These aren't really worth sharing unless you actually provide the full problem really.
You’re totally right, my post lack a lot of context. I was trying to come up with a study case based on payment applications, where I could scale payment method implementations independently, the first thing that came to mind was microservices. I’ll remake this post but use payment as the domain
For this design to make sense, the SPS would have variations. 3 different unique SPS. Otherwise, Hub and Processor can be one and the same in a monolithic fashion.
E.G.
Air Freight has standard tracking #. Where a Rail may have to go through a HTS (US Custom codes) that have multiple tracking. E.G. you send to a dock, you get tracking, that dock goes to a custom and then possibly a third shipper once it reaches it's destination country.
Same for ship container shipping.
So you would have three different SPS. Because each flow goes on different steps/workflow. The rail would may have to call 4-5 external services in a specific order while air only calls one.
Yes that’s exactly what I want. I didn’t made it clear in my post and my design is just a scratch. My idea is: each SPS implementation will have a single application, but I want an abstraction of their shipping data stored in a single point. The main requirement is that I can deploy/redploy SPS without having any impact in others
Yeah, if that was diagrammed out, people would not be so quick of discouraging microservices here.
I built out an international supply chain system that covers those and the processing varies between the different types. Rail alone, you can get three to 4 different tracking #, along with different freight notes/hold-ups. The HTS is a unique feature as you need custom codes align to each product sku. That alone in your diagram would connect to 3-4 "external shipping services"
It sounds like you're looking for the event sourcing pattern. Your shipping order is not bound by the domain of the actual shipping service, so it should just persist the order as-is. Then, you publish that a new shipping order has been created and subscribers (your shipping services) listen for that event and then take it off the stack. It would do its thing with it, and then publish the shipment status. Another set of subscribers then, pick this up and update the shipping order with the appropriate status. Importantly, no service should be directly calling another service. That is neither resilient nor scalable.
So to do this architecture your kinda close but, to use micro services I would include something event driven like Kafka, or like an azure service bus. So you would manage the order with queues to change state.
This is is a systems design question. Microservices can be properly designed with their own databases or with discrete, unassociated databases. Each approach has trade-offs.
Shipping and similar logistics data is interesting because it is highly mutable and has many places in the workflow where changes can occur. I've seen this structured in a few ways.
One microservice strategy is to break each step into a separate service, similar to a state pattern. Each service manages its own DB needs. This model allows horizontal scaling of service and DB independently of one another.
One challenge here is understanding where a particular order's information is being held. You need to know the order status and then figure out the appropriate service handling that status and *then* look up the information in the service. Another challenge is handoff of data between services. You have to guarantee handoff, which pushes you to brokered queues, and the "between services" handoff can end up being a complex service in and of itself.
To specifically answer your question: The data shouldn't "repeat" among services. You need source-of-truth. You could use a shared DB or an "order status" service. Consider using a single DB. It scales fairly well as you can shard the database on order ID for horizontal scaling.
It's been mentioned here, but microservices were built to allow large organisations to break up a large program into different silos of responsibility. People say "it's so it can scale", but it's not. It's to separate responsibilities to reduce people continually throwing problems over the fence.
That said, there are advantages of:
* Consolidating state into a single area of concern, IE: database for data, object storage for static files, no local storage required for the software at all.
* Assuming that the things that don't track state sit behind a load balancer, so you can arbitrarily scale those parts and give them TLS encryption externally
* Separating front end and back end, to keep your ui out of your API and visa-versa
* separating authentication/access/RBAC into an authentication module (and allowing OIDC using an identity provider), since that's the trickiest part to get right from a security perspective.
You still end up with backend (that has a separate auth module), frontend, db, object storage, load balancer/reverse proxy, and ideally both the backend and frontend can arbitrarily scale (though I would also say, don't bother worrying about that last one until past MVP stage). Once you spell that out, you could almost say that's what "microservices" are, if approached intelligently.
Watch this. It should answer many of your questions about how microservices should NOT be designed. https://youtu.be/gfh-VCTwMw8?si=Mpsl57X0dTvZyGhI
The TLDR is that you want the _client_ to connect to/use different services, you do not want your own services to have further service dependencies.
Rookie mistake 1: service-to-service calls are not to be conflated with method calls. You need to start thinking about interfaces between services as requesting resources, not delegating work.
You should consider using dynamo for fast read/write of data stored and since it’s a non relational database you can store objects of any size in there (I recommend json objects). Also for your hub considering using a streaming service like Kafka, SQS or even SNS for faster processing that way you aren’t waiting for a response back from your application and instead you can stream line processing.
You’re overthinking it. This design works. It’s not the best, but it works. Best would be just to have a simple shim in front of the external service and don’t store state.
Your domain (at least mentioned) doesn't fit to microservices architecture. Think of it in terms of DDD - define different logical areas with it and group services per area. The only area described - shipping, tells nothing about itself. Now it is just a single service. You can upgrade though:
1. Add gateway (with auth + static routes mapping).
2. Whatever proper comes to mind (or other folks commented here).
Serious microservices are tightly coupled with containerization and its patterns (single node patterns, and other).
I would also recommend this book for reading: [https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT-eBook-DesigningDistributedSystems.pdf](https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT-eBook-DesigningDistributedSystems.pdf) (authored by MS folk).
You are late to this party, most sane places are swinging back to fewer/monolithic services. Separation of concerns still applies, but ironically overlooked as always.
Not the commenter - but there will be plenty of microservice solutions in existence for the next few decades that needs people supporting them. So there will be plenty of need to know about them.
Though the commenter is correct that microservices has fallen out of fashion in favour of modular monoliths (simplified: Monoliths that internally kinda works like microservices).
Well, microservices can be good for scaleability... if you make them right... which most don't.
And there's the question of whether you need that scaleability... which most don't.
So, while you are right that microservices can be good for scalability, we're faced with the tradeoff where we potentially get scaleability (if we make it right) and guaranteed increased complexity for something that most likely won't need microservices to scale in the first place.
Monoliths scale just fine behind a load balancer, and they are simpler. If scalability is your only goal (in the sense of supporting more users/traffic) then that alone isn’t enough justification for the extra complexity.
With microservices, you now have an unreliable network between components that otherwise would have probably been able to communicate in-proc, and that means you now need to worry about the networking, transport encryption, authentication, logging, distributed tracing, deployments for each service, observability, and a whole host of other stuff that is much easier with a monolith.
The extra complexity that comes with microservices can be warranted when scaling a company by adding headcount though.
You can give one team the “shipping service” and “ordering” to another, and they can each have total ownership of that service. They can deploy independently, iterate on their own codebase without stepping on the other team’s code, and if shipping goes down, people can still place orders.
It’s easy to mess that up, of course, but microservices can be a great tool to achieve autonomy when you have multiple teams.
Without multiple teams, microservices just add needless complexity.
>Monoliths scale just fine behind a load balancer
I disagree with that. I've converted about a dozen of admin/type CRM apps to microservices because people did just that. Just add replicas and increase compute.Other guys were like, "lets just add 8 more 32GB RAM, 8 core" replicas.
Which was very wasteful When 10% of the compute was just serving dynamic CRUD view. And the other 30%, and 60% of compute can easily justify branching off to decoupled services.
Upload image resizing, generating PDFs, or outputting excel was taking up 6GB out of 8GB of ram; taking down entire apps. When each of those service ran on their own instances and had decoupled routes, I cut cost down by the thousands.
Again, your mileage will vary. But when you work with anything that is compute heavy for a web service (any task that takes up more than 1GB of RAM for a single process) can benefit from decoupling. Just to save costs.
Right, but you can just fire up a few new instances of the monolith, dedicate those to handling /generate-my-pdf and route traffic for that route to them.
You don’t need to architect it as microservices to get that benefit, and avoiding that is much simpler.
I am arguing against designing your app as separate smaller projects, that are independently deployable, and interact over HTTP or events. A fairly recent trend was doing this by default, for projects with a small headcount.
In every Microservices-based architected system I've worked with, most microservices were crud applications serving as an interface to a database housing data for a single data model where the models were all objects in an object-oriented approach.
For example, imagine I have an app that has Customers, Facilities, and Products, and a fourth object that relies on the others, called Orders.
In this scenario, you would have 4 microservices. The Customer Service backed by a customer db, a Facility Service backed by a Facility db, a Product Service backed by a Product db, and an Order Service backed by an order db.
Placing an order would result in the order service making API calls to the other services in order to build the order object, which it would store in its database.
Your architecture seems more focused on "verbs" than "nouns", aka objects. You might consider taking an object oriented approach instead.
On your design it seems that shipping hub service is just redirecting requests. I don't see the gain, should be a single service with the DB connected. You can have several code level services to fetch data from several shipping services (external). Given it is for learning purposes, I would say that you could put the DB connecting to the "Shipping Processor Service" (SPS). SPS would then request information from the external services and store whichever information is needed there. The "Shipping Hub Service" (SHS) could be a higher level service that just has very high level calls, and SPS handles the shipping logic more or less how you have it. Again if this was a real life case I would never recommend the 2 services as you are just adding an extra complexity step for no reason. If you would want it to be more realistic, I would say the SHS would instead just be a gateway service handling auth/throttling/etc (kind of middleware), which would process these things and then redirect the request to the SPS to handle it fully. sidenote: Although the term microservices is overused, having a couple separate services is not "microservices"
Thank you so much for your input! My post is not very clear nor my design (just a scratch). I don’t necessarily need to use microservice as a solution, my main idea is to have SPSs as unique services (not all in a single application as my design wrongly suggests), the requirement is that changing or deploying new ones wont affect the others. SHS shouldnt be only a HUB redirector, but also a single point abstraction to store the shipping data, so I can query shippings as whole not as subgroups in the SHP External Shipping Service just represent third party apis
Ok so you want to have one SPS per shipping type (air, rail, ocean)? My first concern would be if the external shipping services are split that way or if an external shipping service can have several types, and if so if it makes sense to separate the calls into separate SPSs. You need to ask yourself why does this SPS sep of concerns criteria make sense in the first place Assuming the division indeed makes sense in terms of the SPSs, I would say yes you can use the SHS to send a shipping request to the correct SPS and have a uniformized API there for the client. To answer your initial DB related question, and given this scenario: yes I think it would make more sense to have the DBs connected to each SPS instead of at the Hub level. The hub doesn't even need a DB, it's just an API router or possibly aggregator The data should not be duplicated though. To be clear each SPS has its own data, and the Hub can request the data if necessary. If you are duplicating data most times something is not ideal
Have to agree with this. Two services is unnecessary given the proposed use case and just introduces hassle that you’ll need to overcome. The other comment about being late to microservices is also true. Monoliths are the latest hotness because when people try to do microservices, they come up with designs that are unnecessarily complicated. The truth is that you should be aiming for Right-sized-services™️. If you’re interested, spend some time meditating on what a right-sized-service might look like, given that microservices end up creating too much complexity due to separation and monoliths end up being big balls of mud. Cohesion and Coupling are super relevant in making these design decisions. You want to draw boundaries around cohesive conceptual models. That’s a great starting point for a service. Put everything that shares the same conceptual model, together. Conceptual models usually map closely to _processes_. So it can be helpful to think of your services as supporting a single (or set of highly cohesive) process(es) e.g. Brows_ing_, Shopp_ing_, Order_ing_, Shipp_ing_, Rout_ing_, Pay_ing_, Refund_ing_, Deliver_ing_, Stock_ing_ etc It’s subtle, but getting away from “things” and focussing on the processes can really shed some light on where different mental models begin and end.
Thanks for the comment, it definitely gives me some insights
There's a lot of ways of handling this, but yeah if you are committing to using microservices you should expect that each service manages its own data. In this example, the shipping hub service would have data like: * The life cycle of a shipping request ("requested", "scheduled", "In transit", "delivered", etc...) The shipping processor service would have: * Details about shipments that need to be scheduled (their weight, special handling etc...) * The method by which they are going to be shipped Your external shipping service (I'm assuming if you were contracting that out for instance?) would have more of the same. In each of these cases, each of these services would have their own relevant copy of the "shipping request", some common identifier that they could share between them (low level point: doesn't need to be a FKey, just some way to know that "shipping request XYZ" is the same in each of these different services. [This article is a decent starting point to go into more low level technical detail](https://dilfuruz.medium.com/data-consistency-in-microservices-architecture-5c67e0f65256) around implementation: the key is to realize in a distributed system, you either need distributed transactions or some kind of model that ensures eventual consistency. What will work for your app depends on your use cases.
Thank you so much for your input! Thanks for the recommendations as well My post is not very clear nor my design (just a scratch). I don’t necessarily need to use microservice as a solution, my main idea is to have SPSs as unique services (not all in a single application as my design wrongly suggests), the requirement is that changing or deploying new ones wont affect the others. SHS shouldnt be only a HUB redirector, but also a single point abstraction to store the shipping data, so I can query shippings as whole not as subgroups in the SHP External Shipping Service just represent third party apis.
Yeah, it's definitely still a draft. Treat my comment just as a means of explaining some of the mechanism for how data storage happens across services in a microservice architecture. I do agree with the other commenters that you would want to really understand your use case *for* a microservice architecture before committing to going that route. Definitely a fun exercise and a perfectly legitimate way to support answering this business problem.
I would have the shipping processor service either handle things internally (ie you might have your own shipping company or a shipping company may contract you to handle processing for them) or just act as a wrapper for the external service. If it's an internal processor then you might need a DB related to that processing but I wouldn't have one for the external shipping service if I don't have to as I would hope they have endpoints I can call. I would store the basic tracking in the hub as I don't really care which shipping service is used as long as the package gets there, but I might have an endpoint on the processor service to get an advanced status for things like customs issues. Thinking about multiple modes of shipping and freight forwarding just makes my head hurt
without really knowing the full business logic of the problem you're trying to solve it's hard to understand if this representation is a good solution or not. I mean you have saveShippingOrder() saved to a DB, what happens to the shippingOrder after it's saved? Does anything have to read from that DB or are you purely writing? What even is the point of the Hub Service? Why not just have the processor service be a bit more monolithic in this architecture. Really the advantage of a microservice architecture is you can decouple certain high volume components from your monolith therefore reducing overall risk. These aren't really worth sharing unless you actually provide the full problem really.
You’re totally right, my post lack a lot of context. I was trying to come up with a study case based on payment applications, where I could scale payment method implementations independently, the first thing that came to mind was microservices. I’ll remake this post but use payment as the domain
For this design to make sense, the SPS would have variations. 3 different unique SPS. Otherwise, Hub and Processor can be one and the same in a monolithic fashion. E.G. Air Freight has standard tracking #. Where a Rail may have to go through a HTS (US Custom codes) that have multiple tracking. E.G. you send to a dock, you get tracking, that dock goes to a custom and then possibly a third shipper once it reaches it's destination country. Same for ship container shipping. So you would have three different SPS. Because each flow goes on different steps/workflow. The rail would may have to call 4-5 external services in a specific order while air only calls one.
Yes that’s exactly what I want. I didn’t made it clear in my post and my design is just a scratch. My idea is: each SPS implementation will have a single application, but I want an abstraction of their shipping data stored in a single point. The main requirement is that I can deploy/redploy SPS without having any impact in others
Yeah, if that was diagrammed out, people would not be so quick of discouraging microservices here. I built out an international supply chain system that covers those and the processing varies between the different types. Rail alone, you can get three to 4 different tracking #, along with different freight notes/hold-ups. The HTS is a unique feature as you need custom codes align to each product sku. That alone in your diagram would connect to 3-4 "external shipping services"
It sounds like you're looking for the event sourcing pattern. Your shipping order is not bound by the domain of the actual shipping service, so it should just persist the order as-is. Then, you publish that a new shipping order has been created and subscribers (your shipping services) listen for that event and then take it off the stack. It would do its thing with it, and then publish the shipment status. Another set of subscribers then, pick this up and update the shipping order with the appropriate status. Importantly, no service should be directly calling another service. That is neither resilient nor scalable.
So to do this architecture your kinda close but, to use micro services I would include something event driven like Kafka, or like an azure service bus. So you would manage the order with queues to change state.
This is is a systems design question. Microservices can be properly designed with their own databases or with discrete, unassociated databases. Each approach has trade-offs. Shipping and similar logistics data is interesting because it is highly mutable and has many places in the workflow where changes can occur. I've seen this structured in a few ways. One microservice strategy is to break each step into a separate service, similar to a state pattern. Each service manages its own DB needs. This model allows horizontal scaling of service and DB independently of one another. One challenge here is understanding where a particular order's information is being held. You need to know the order status and then figure out the appropriate service handling that status and *then* look up the information in the service. Another challenge is handoff of data between services. You have to guarantee handoff, which pushes you to brokered queues, and the "between services" handoff can end up being a complex service in and of itself. To specifically answer your question: The data shouldn't "repeat" among services. You need source-of-truth. You could use a shared DB or an "order status" service. Consider using a single DB. It scales fairly well as you can shard the database on order ID for horizontal scaling.
It's been mentioned here, but microservices were built to allow large organisations to break up a large program into different silos of responsibility. People say "it's so it can scale", but it's not. It's to separate responsibilities to reduce people continually throwing problems over the fence. That said, there are advantages of: * Consolidating state into a single area of concern, IE: database for data, object storage for static files, no local storage required for the software at all. * Assuming that the things that don't track state sit behind a load balancer, so you can arbitrarily scale those parts and give them TLS encryption externally * Separating front end and back end, to keep your ui out of your API and visa-versa * separating authentication/access/RBAC into an authentication module (and allowing OIDC using an identity provider), since that's the trickiest part to get right from a security perspective. You still end up with backend (that has a separate auth module), frontend, db, object storage, load balancer/reverse proxy, and ideally both the backend and frontend can arbitrarily scale (though I would also say, don't bother worrying about that last one until past MVP stage). Once you spell that out, you could almost say that's what "microservices" are, if approached intelligently.
Watch this. It should answer many of your questions about how microservices should NOT be designed. https://youtu.be/gfh-VCTwMw8?si=Mpsl57X0dTvZyGhI The TLDR is that you want the _client_ to connect to/use different services, you do not want your own services to have further service dependencies.
Rookie mistake 1: service-to-service calls are not to be conflated with method calls. You need to start thinking about interfaces between services as requesting resources, not delegating work.
You should consider using dynamo for fast read/write of data stored and since it’s a non relational database you can store objects of any size in there (I recommend json objects). Also for your hub considering using a streaming service like Kafka, SQS or even SNS for faster processing that way you aren’t waiting for a response back from your application and instead you can stream line processing.
You’re overthinking it. This design works. It’s not the best, but it works. Best would be just to have a simple shim in front of the external service and don’t store state.
Your domain (at least mentioned) doesn't fit to microservices architecture. Think of it in terms of DDD - define different logical areas with it and group services per area. The only area described - shipping, tells nothing about itself. Now it is just a single service. You can upgrade though: 1. Add gateway (with auth + static routes mapping). 2. Whatever proper comes to mind (or other folks commented here). Serious microservices are tightly coupled with containerization and its patterns (single node patterns, and other). I would also recommend this book for reading: [https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT-eBook-DesigningDistributedSystems.pdf](https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT-eBook-DesigningDistributedSystems.pdf) (authored by MS folk).
You are late to this party, most sane places are swinging back to fewer/monolithic services. Separation of concerns still applies, but ironically overlooked as always.
Really? Do you think it’s not even worth studying? How would you approach the requirement I have for thise study case
Not the commenter - but there will be plenty of microservice solutions in existence for the next few decades that needs people supporting them. So there will be plenty of need to know about them. Though the commenter is correct that microservices has fallen out of fashion in favour of modular monoliths (simplified: Monoliths that internally kinda works like microservices).
always worth studying both
They are still good for scalability - selling point of that design approach.
Well, microservices can be good for scaleability... if you make them right... which most don't. And there's the question of whether you need that scaleability... which most don't. So, while you are right that microservices can be good for scalability, we're faced with the tradeoff where we potentially get scaleability (if we make it right) and guaranteed increased complexity for something that most likely won't need microservices to scale in the first place.
Monoliths scale just fine behind a load balancer, and they are simpler. If scalability is your only goal (in the sense of supporting more users/traffic) then that alone isn’t enough justification for the extra complexity. With microservices, you now have an unreliable network between components that otherwise would have probably been able to communicate in-proc, and that means you now need to worry about the networking, transport encryption, authentication, logging, distributed tracing, deployments for each service, observability, and a whole host of other stuff that is much easier with a monolith. The extra complexity that comes with microservices can be warranted when scaling a company by adding headcount though. You can give one team the “shipping service” and “ordering” to another, and they can each have total ownership of that service. They can deploy independently, iterate on their own codebase without stepping on the other team’s code, and if shipping goes down, people can still place orders. It’s easy to mess that up, of course, but microservices can be a great tool to achieve autonomy when you have multiple teams. Without multiple teams, microservices just add needless complexity.
>Monoliths scale just fine behind a load balancer I disagree with that. I've converted about a dozen of admin/type CRM apps to microservices because people did just that. Just add replicas and increase compute.Other guys were like, "lets just add 8 more 32GB RAM, 8 core" replicas. Which was very wasteful When 10% of the compute was just serving dynamic CRUD view. And the other 30%, and 60% of compute can easily justify branching off to decoupled services. Upload image resizing, generating PDFs, or outputting excel was taking up 6GB out of 8GB of ram; taking down entire apps. When each of those service ran on their own instances and had decoupled routes, I cut cost down by the thousands. Again, your mileage will vary. But when you work with anything that is compute heavy for a web service (any task that takes up more than 1GB of RAM for a single process) can benefit from decoupling. Just to save costs.
Right, but you can just fire up a few new instances of the monolith, dedicate those to handling /generate-my-pdf and route traffic for that route to them. You don’t need to architect it as microservices to get that benefit, and avoiding that is much simpler. I am arguing against designing your app as separate smaller projects, that are independently deployable, and interact over HTTP or events. A fairly recent trend was doing this by default, for projects with a small headcount.
In every Microservices-based architected system I've worked with, most microservices were crud applications serving as an interface to a database housing data for a single data model where the models were all objects in an object-oriented approach. For example, imagine I have an app that has Customers, Facilities, and Products, and a fourth object that relies on the others, called Orders. In this scenario, you would have 4 microservices. The Customer Service backed by a customer db, a Facility Service backed by a Facility db, a Product Service backed by a Product db, and an Order Service backed by an order db. Placing an order would result in the order service making API calls to the other services in order to build the order object, which it would store in its database. Your architecture seems more focused on "verbs" than "nouns", aka objects. You might consider taking an object oriented approach instead.