I've done a lot of fault tolerant stuff that scales to billions of users. A very high level way to achieve this, is something like:
The app with a default action if the API doesn't work
The end point of the app with a default action if its deeper actions don't work
Scale more servers/instances if needed, use a great reverse-proxy or API gateway scheme
It's okay to use macro services (instead of a micro server per every granularity -- an approach I call NanoServices because there's so many, you'd share a few related features together)
You don't really have to have a different database per micro service. You can use a monolithic data approach just make sure no two services acto on the same data in the same way. Were that the case, do cross service calls
It's okay to have higher level services that act as orchestrators to avoid cross-service communication
If you really need a lot of cross service communication, using a ServiceBus or Event-Driven architecture will help you.
The more microservices the more maddening it'll be maintaining them without a very good DevOps/automation strategy. Because of this we took more of a macro service architecture than a micro/nano service on. Now that we have all the automation, we're breaking each controller into a microservice as it should be. Prologinging this step has saved us a lot of pain.
Keep it as simple as possible.
For faul tolerance, that really only works if you have a failover system, a way to get to an alternate behavior, or a way to avoid a non-essential behavior. It's easier to start with a default alternate behavior (in the app, then in the service) then a scale up/failover in the DevOps side. That way you can get some reliability and time to do the hard stuff.
I've done a lot of fault tolerant stuff that scales to billions of users. A very high level way to achieve this, is something like:
The app with a default action if the API doesn't work
The end point of the app with a default action if its deeper actions don't work
Scale more servers/instances if needed, use a great reverse-proxy or API gateway scheme
It's okay to use macro services (instead of a micro server per every granularity -- an approach I call NanoServices because there's so many, you'd share a few related features together)
You don't really have to have a different database per micro service. You can use a monolithic data approach just make sure no two services acto on the same data in the same way. Were that the case, do cross service calls
It's okay to have higher level services that act as orchestrators to avoid cross-service communication
If you really need a lot of cross service communication, using a ServiceBus or Event-Driven architecture will help you.
The more microservices the more maddening it'll be maintaining them without a very good DevOps/automation strategy. Because of this we took more of a macro service architecture than a micro/nano service on. Now that we have all the automation, we're breaking each controller into a microservice as it should be. Prologinging this step has saved us a lot of pain.
Keep it as simple as possible.
For faul tolerance, that really only works if you have a failover system, a way to get to an alternate behavior, or a way to avoid a non-essential behavior. It's easier to start with a default alternate behavior (in the app, then in the service) then a scale up/failover in the DevOps side. That way you can get some reliability and time to do the hard stuff.
Thank man for deep explanation.❤️❤️❤️