Should the cache go in front of my app or between the app and the database?

Put the shared cache between the application and the database, and treat that as the default. A cache in front of the application earns its place only for the portion of a response that every reader receives identically; anything assembled per person stays behind the application, where the code can see who is asking.

Start with what a hit costs at each rung, because that is the argument usually made for keeping the copy as close to the code as possible. A map inside the service process answers in the time it takes to follow a pointer, 0.0002 milliseconds. The shared tier beside the store is one round trip away, 0.4 milliseconds. Dividing one by the other:

Move the copy the other way, in front of the application instead of behind it, and the gain and the loss both change. A layer near the reader removes geography, and geography is most of what a distant reader waits for: in one traced request the nearby point of presence is reached in 18 milliseconds, the crossing to the data centre costs 112 milliseconds, so 94 of those milliseconds are distance and no work inside the data centre touches them. What the outer layer cannot do is see who is asking. It answers before your code runs, so it has no user, no session and no permissions row. A page assembled per person therefore cannot be held there whole: key it by address and one reader is served another reader's page, key it by user and each entry is wanted by exactly one person, which is a cache with a hit rate near zero and a privacy problem attached. The remedy is to split the response, with the part everybody shares going out to the near layer at 18 milliseconds and the small personal remainder coming back for the 112 millisecond crossing.

The arithmetic that makes an outer layer worth its risk is the nesting of the two costs. Let the near layer answer a share $p$ of reads at $\ell$ milliseconds, let the shared tier answer a share $q$ of what gets past it at $m$ milliseconds, and let the store cost $s$. Then

With $p = 0.7$, $\ell = 18$, $q = 0.9$, $m = 112.4$ and $s = 130$, the second bracket is $0.9 \times 112.4 + 0.1 \times 130 = 101.16 + 13 = 114.16$ milliseconds, and the whole expression is $0.7 \times 18 + 0.3 \times 114.16 = 12.6 + 34.25 = 46.85$ milliseconds. Without the near layer the same traffic averages the full 114.16. The outer copy wins not by being fast in itself but by multiplying everything underneath it by the thirty percent that got past, which is why it belongs in front of the part of the page that is shared rather than in front of the part that is personal.

The in-process map has a matching failure at the other end, and it is arithmetic rather than opinion. With only a shared tier, a share of 0.08 of reads falls through to it. Add a local map to every process and the share that reaches the tier becomes $0.08 + 0.30\left(1 - e^{-n/16}\right)$ for $n$ processes: at one process that is $0.08 + 0.30 \times 0.0606 = 0.098$, and at sixty four processes it is $0.08 + 0.30 \times 0.9817 = 0.373$. The local layer barely changes the picture when there is one process and makes it nearly five times worse for the tier below when there are sixty four, because each process now sees a sixty fourth of the traffic, warms slowly, and duplicates the misses of its neighbours. Forty copies also disagree with each other, so two readers asking the same question land on different processes and get answers of different ages.

Two conditions flip the advice. If the service runs as a single process, the local map and the shared tier collapse into the same decision: one copy, one expiry schedule, and the objection to keeping it in the process disappears. If the answer is wanted by one person and must be current, neither rung holds it and it should not be cached at all. Between those extremes the test is two questions asked of each field in the response: who else wants this answer, and how old may it be? Something every reader wants that may be minutes stale goes as far out as it can reach. Something one reader wants that must be seconds fresh stays close in, or goes uncached.

The shared tier beside the store costs 0.4 milliseconds against the local map's 0.0002 and repays it with one warm copy for the whole fleet, one invalidation, and capacity you provision rather than capacity that happens to be spare. That is why it goes between the application and the database. The local map is then an optimisation applied to the few entries whose round trip you cannot afford, and the layer near the reader is an optimisation applied to the shared shell of the page, not to the page.