Opening the system to be more microservice oriented

As for now, my system is a kind of hybrid.
one part is a react client speaking to a monolith server for crud operations.
The monolith app also calling my own long-running async services in another SS host, each service reports back to the monolith app. Service A,B, and C are long-running services and can report back after several minutes.


Its kind of getting bigger and the remote services now need to be deployed in a different data-center. the number of requests also getting bigger and bigger and I need to split each service to a different container.

This is where I think I should be soon:

  1. Monolith app calling the API-gateway which manages all side’s security.
  2. Create another host that handles the reporting back and saves it to the database.
  3. Maybe a queue to handle all the traffic.
  4. Have multiple containers per remote service.


I would love to know what do you think about the design. also, do you have a sample project/s that takes advantage of all of what I wrote here?
Cross host security, api gateway, service execution queue and such…
Also, can this be fully implemented by SS, or do I need the help of external libs such as ocelot.


See this previous post on Microservices shared front end aka How does servicestack find services? on starting with a Monolith then split out Services when needed, use the Service Gateway to enable loose-coupling for inter-process Service calls, and you’d typically want to use JWT for authentication.

As to the correct design, you should almost always start with a Monolith first, but design your App so it can be easily split up, e.g. maintain proposed Microservice implementations in different decoupled .dll’s where only inter-coupling between them should be sharing the same DTOs & using the Service Gateway for communication, which will allow you to easily extract the Service implementation into a different AppHost that can then be accessed remotely.

So whilst it’s advisable to be designing your monolith “for Microservices” so it can be easily split out into different microservices, doing so adds more complexity, latency & performance & maintenance overhead, deployment overhead, lower productivity, multiple PoFs, etc so you should have very clear tangible value for doing so, it need not only be technical, e.g. a valid reason for a Microservice is there are different teams working on them who’d prefer to develop & release on their own cadence.

Definitely don’t just add infrastructure dependency if you don’t know you absolutely need it. Each adds an additional PoF. It should be evident when you need features like a MQ, e.g. for facilitating requests that are no longer suitable to be executed synchronously, like long-running time-decoupled async oneway operations.

Talking about system design in abstract is not going help with your decisions. The question you should be continually asking is what benefit will I get from splitting out into a remote host? and does it justify the additional overhead? e.g. Why are you splitting your API Gateway from your Monolith, it already looks like it was adopting the role of an API gateway?

Do all requests need to go through a monolith, e.g. can your Services be called directly. If you adopt JWT only the monolith needs to be concerned about Authentication & issuing new tokens which can embed what roles/features (Audience) each user is allowed to access to, each Service then only needs to validate the JWT & check that they’re allowed access to the feature/Service.

Others on here may have different recommendations, but mine is always going to be design your systems simplicity-first where the correct number of Microservices being the minimum number required.

Hi thank you!

This is exactly my use-case, task that are lasting between 1-5 minutes.

This is actually a commercial thing, the services 1,2 and 3 needs to sit in a remote host and many clients will speak with them. the monolith app is not a multi-tenant. each customer will have its own deployment.

  1. Is the api gateway also be used as a proxy? since my deployment is splitted into multiple datacenters.
  2. Do you have a sample project/s that takes advantage of most of what mentioned here?
  3. Do you think that SS Consul is a good approache for distributed services (accross datacenters)?

Thanks again!

That’s effectively what it looks like it’s doing already.

You can find all ServiceStack example projects at the end of the Getting Started Page, for simplicity all our examples projects only have a single AppHost.

The 1 example & Project Template that does have multiple Hosts is the MVC Identity Server example from the mvcidentityserver project template which shows an example of using an external Central IdentityServer & Authentication with downstream API Servers. Note: IdentityServer is developed, maintained & supported by the team who offer their own training, consulting & support.

Depends on how many distributed Services you have, there’s an initial complexity cost, but the more you have the more value it can provide. The ServiceStack.Discovery.Consul
is a community project developed by @mac & has had contributions from @Rob who may be able to provide additional insight.

Thanks. one last thing, I see that the SS consul is not so maintained. last commit is 2 years ago.
is it stable and uptoday with consule changes?


That’s a question for the maintainers, but does highlight we should look into a better way of bringing in community projects as part of the CI & release process so they can be released at the same time with updated dependencies as the rest of ServiceStack.

1 Like