@Rod: Do beware of the busy test system which slows down production too. I remember one instance of a performance test being run which was slowing down production -- due to unexpected sharing of some hardware, somewhere -- and it was NOT fun :/

@ArseniMourzenko: That'd be a good place to start.

Do you have an order of magnitude of (1) the amount of data the database reads from the disk, (2) the amount of data the database needs in memory, and (3) the amount of data exchanged (both ways) between the application and the database? (Discount any overhead here, just count the amount of user data) -- Often times I've found that users expect a query to be fast because it returns little data, without accounting for how much the database needs to read from disk, or how much works it needs to do to compute said data, but without numbers it's hard to gauge...

@DavidMulder: That's completely orthogonal. The manager still need to be authentified (to prove they're the manager) so it'd still be a private endpoint. No reorganization required.

@DavidMulder: I could see public-vs-private being blurry -- specifically, I could public endpoints becoming private -- but opening admin endpoints to the general public is a terrible idea in general, security-wise: you're better off redoing a new endpoint from scratch.

I do like the clear separation. In fact, I would make it even more explicit and have part of the path be public (unauthenticated traffic), private (authenticated traffic), or admin (administration traffic) so no mix-up is possible.

@Technophile: with regard to reset of limits, I typically recommend a sliding window approach => it's works regardless of the limits are reset on the server side.

A separate access layer has indeed multiple advantages, the first of which being data validation. It's not always easy, or practical, to enforce data integrity in the database itself, in which case it can be handled by a layer on top... and DRY dictates there be a single layer. Caching is only a potential cherry on top, really. On the other hand, YAGNI.

@AlexanderThe1st: On the other hand, YAGNI.

This! The notion of level is very important here. I have used sequence diagrams to communicate with in-house developers of other applications, or even developers from outside the company which needed to interact with our API. These developers care NOT AT ALL for the name of classes & methods within my code, that is much too detailed. The sequence diagram needs to be focused on what the audience will interact with. If the audience uses a REST API, that is what the diagram should focus on, if it uses a library, that is what the diagram should focus on.

I like this answer a lot, except with regard to blindly accepting what's in the database. It's too bad that bad data made it to the database, but that doesn't mean it should be propagated any further, or throw more processing off. For typical OLTP for example, better refuse to work with product ID 47 because it's broken, and page someone to have a look and purge it or fix it, than start propagating the brokenness.

@candied_orange: Yes, I would. It need not be extensive, but some mention of how CPU caches can reduce the impact of access latency of certain access patterns (such as linear access) to the point where it becomes negligible would make it a better answer, I think. Streaming/Chunking strategies typically require more complex code, so they need to justify this complexity by bringing advantages compared to straightforward Slurping. If the Slurping is mechanically sympathetic and Streaming/Chunking brings next to no performance advantage... they may just not be worth it.

@candied_orange: No, because that's an extreme position and extremes are never valid. My claim is that access latency is a more nuanced topic than your answer may suggest, especially given pre-fetching.