This is exactly what I see all the time in the wild:
- users service
- quotes service depends on users service
- notes service depends on quotes service
So... notes depends on users. Unless I'm missing something, I would not distribute this example ever in a million years. Most requests probably pull back all three pieces of data, so just do it in a single query. Do not introduce unnecessary extra network latency to aggregate the data. If you want to scale this horizontally then just add a load balancer in front of n copies of the single service.
Now, let's look at an example you might want to distribute:
- web service (API)
- video encode service (Running on specialized hardware)
Now we have an actual reason to separate our services, we want to take advantage of specialized hardware for our long-running, async video encode tasks while leaving our standard synchronous API responsive.
Another reason to distribute:
- Team A works on API A
- Team B works on API B
This allows each team to reduce the scope of their knowledge by focusing on a single API, but comes at the expense of extra network calls, serde, API negotiation, and versioning.
- users service
- quotes service depends on users service
- notes service depends on quotes service
So... notes depends on users. Unless I'm missing something, I would not distribute this example ever in a million years. Most requests probably pull back all three pieces of data, so just do it in a single query. Do not introduce unnecessary extra network latency to aggregate the data. If you want to scale this horizontally then just add a load balancer in front of n copies of the single service.
Now, let's look at an example you might want to distribute:
- web service (API)
- video encode service (Running on specialized hardware)
Now we have an actual reason to separate our services, we want to take advantage of specialized hardware for our long-running, async video encode tasks while leaving our standard synchronous API responsive.
Another reason to distribute:
- Team A works on API A
- Team B works on API B
This allows each team to reduce the scope of their knowledge by focusing on a single API, but comes at the expense of extra network calls, serde, API negotiation, and versioning.
It cannot be overstated the convenience of:
Jump to code definition, update function, compile, fix compilation errors, code works.