Can you explain this a little bit more? You keep a counter on the user object in the DB? What is the JWT buying you if you still have to hit the DB on every request?

Presumably you can keep counters like these on the server edges, and just push new values out to servers whenever things change, as opposed to query a DB every time. This wouldn't invalidate individual tokens however, but all tokens that have that counter value. It'd also mean there's a window where tokens can still be used while servers are being updated with the new value(s).

These are just some random and half-baked thoughts, I have no idea what OP does, but there are options to limit hitting backing DBs anyway.

Yep ^ This is what I often do too. Simple, but effective.

That's pretty smart. Effectively versioning your issued tokens. Way easier than maintaining a blacklist.

You can store the user info in the JWT so you don't need to hit the database to get user info every time. I usually just store an id in each issued token and store/remove it from redis or memory as needed for invalidating it.

You have to be careful that you are not leaking sensitive info though, as the JWT payload is meant to be visible on the client as well.