4

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.

Improve this question
1
  • This probably depends on how the services are deployed. Are they on baremetal? Kubernetes? Custom vms? Generally speaking, unless the two services are very heavy and use a lot of computing resources, leaving them as two seperate services is probably easier than having to deal with the networking fiasco of exposing part of an internal api, and refactorig the old api to also do authentication when it sounds like it previously was not
    – joshmeranda
    Commented Jun 3, 2022 at 2:53

1 Answer 1

Reset to default
3

You want an API gateway. This gives you a tool that can expose APIs to the public using any url you want and have the functionality where it already existed. The gateway is responsible for auth of external users and pass through valid requests. Most commercial gateway products can also allow for some scripting to do basic validations, and can serve as a single point for things like throttling or rate limiting for public users.

An API gateway exists to create a public face for internal process, it can make separate services appear to be the same service to an end user, or allow a single call to be sent to multiple services. The key is that a gateway is basically their to route requests, not do business logic. It may be tempting to add lots of specific validations in, but those should really stay with the actual service and only the most basic checks should get done here, like numbers are numbers or the request is valid json.

It still may make sense to deploy separate versions of your backend service, but ideally this could be a simple config difference of allow gateway traffic or not. This gives you the ability to have a more complete separation if there is a concern about that (you still end in the same db so it's not complete isolation), but you do prevent any complexity from growing in the code.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.