I actually implemented domain driven design WITH an Api-layer ( so core, application, Infrastructure + api). They also are split on Basket, catalog, checkout, shipping and pricing domain with seperate db's.
So just splitting up the heaviest part (eg. Catalog) into "a microservice" would be easy while I add nginx as load balancer. I already separated domain vs Integration Events.
Both now use events in memory in the application, I only need a message broker like NATS then for the integration events.
It would be a easy wall ;). I have multiple options like heavier hardware, splitting up the db from application server or splitting up a domain bound api to a seperate server.
As long as I don't need multimedia streaming, kubernetes or implement Kafka the future is clear.
Ps. Load balancing based on tenant and cookie would be a easy fix in extreme circomstances.
The thing I'm afraid for the most is hitting the identity server for authentication/token verification. Not sure if it's justified though.
Side note: one application has an insane amount of complex joins and will not scale :)
So just splitting up the heaviest part (eg. Catalog) into "a microservice" would be easy while I add nginx as load balancer. I already separated domain vs Integration Events.
Both now use events in memory in the application, I only need a message broker like NATS then for the integration events.
It would be a easy wall ;). I have multiple options like heavier hardware, splitting up the db from application server or splitting up a domain bound api to a seperate server.
As long as I don't need multimedia streaming, kubernetes or implement Kafka the future is clear.
Ps. Load balancing based on tenant and cookie would be a easy fix in extreme circomstances.
The thing I'm afraid for the most is hitting the identity server for authentication/token verification. Not sure if it's justified though.
Side note: one application has an insane amount of complex joins and will not scale :)