Make getUser faster | Engineer Atlas

You asked

“Profiling shows `getUser` is called on every request and the database round trip dominates. Can you make it faster?”

The model answered

1const userCache = new Map<string, User>()
2 
3export async function getUser(id: string): Promise<User> {
4  const cached = userCache.get(id)
5  if (cached) return cached
6 
7  const user = await db.users.findOne({ where: { id } })
8  if (!user) throw new NotFoundError('user', id)
9 
10  userCache.set(id, user)
11  return user
12}

Assistant · I added an in-memory cache in front of the lookup. After the first call for a given id, getUser returns immediately without touching the database, which removes the round trip you were seeing in the profile.

Classify each statement

0/9 classified. Some statements are true — the point is telling which.

For a warm id, the function no longer performs a network round trip to the database.

A user who changes their email or is deactivated continues to be served with the old record from this process.

Memory used by the cache grows with the number of distinct ids requested since the last restart.

Every running instance of the service will return the same answer for a given id.

After a deploy, the first burst of requests for a popular id all reach the database at once.

A cache hit costs a single hash lookup regardless of how many users are cached.

Whether caching is appropriate here depends on how often user records change relative to how often they are read.

Any cache in front of this lookup exchanges some freshness for lower latency.

The correct cache design depends on how many instances serve this function and whether they must agree.