I was having a conversation with a colleague and although my opinion makes sense to me, I wasn’t able to back it up. I’m in the process of creating an API that will be hit hundreds of thousands of times per day. It’s fairly simple, and will just be doing some inserts into a relational database. There are essentially 3 functions I would need to create. The question is, what would have better performance, creating one API with different controllers (using .NET Web API or NodeJS something like that) or 3 different API’s.
My thought is that, for example with the .NET Web API, no matter whether there are 1 or 3 they are all being hosted, and using the same resources. His thought was that having 3 API’s would be 3 times faster because it would have 3 times the resources. I simply didn’t have the proof to disprove that.
I think the performance cost of 1 copy versus 3 for an API being hit “hundreds of thousands of times per day” is fairly negligible; either way, they must both share some of the same resources, and be subject to the same potential bottlenecks.
What I’d be more concerned with is the additional cognitive overhead of having 3 APIs, in terms of server maintenance, codebase maintenance and development for the consumers of the API(s). Regardless of whether having 3 distinct APIs gives any kind of performance boost, I would question whether it actually makes sense.
For example, having create, read and update actions for a resource on separate APIs (and by separate I mean differing (sub)domains eg readApi.example.com versus writeApi.example.com) makes no sense. The only thing this does is force developers to remember that reading and writing a resource live in different places, and force you to document that fact.
If it turns out that one action is a lot more costly than any other, or is being a resource hog, you might consider putting the API behind a load balancer which directs all requests for that action to a different server, but crucially keeps the API URIs intact. I suspect this is may actually be what your colleague is meaning by having more than 1 API.
However, in the case of a pair of APIs for disparate subsystems, which happen to share a database, separated APIs might make sense.