I wanted to understand what are the best industry practices and the pros-cons in the following 2 choices:
- A single service that serves internal only API and public API, vs
- 2 separate services - one for internal only API and another for the public API
I would like to add more context as I understand the answers will depend from situation to situation:
- The product has many (>20) services, most of which are internal only. Only few (<5) of them have a public facing endpoint.
- I have a hyper critical service X that is currently only being used by the remaining services and does not have an external facing public endpoint.
- We want to add public facing APIs that are related to the purposes of X - CRUD. (Modifies the same database and tables). The public facing API will internally call the internal only API of X after some authorization, security checks, and validations.
Pros-Cons so far
Having a separate service puts a clear separation of boundary b/w a public facing service vs an internal only service. This comes with security benefits as well as operational benefits e.g. separate ratelimits, DDoS protection, service load, separate resources (cpu, memory, etc), downtime does not effect X, etc. It also however comes with the additional operational costs - one more service to manage and the added company costs of it. But are the cost-saving of having the same service serving both endpoints more than the operational costs of having a new service? What are some of the other pros and cons that are for each of the choices? Would like to hear your thoughts.