Since you don't store tokens in the database you can't invalidate them remotely. But there are some common practices to overcome this issue.

NOTE: These are not standards, Just a practice used by major companies.

1. Store tokens in Cache Database (Not in the main DB)

Storing JWT tokens in the cache database such as Redis or Memcached will allow you to retrieve and verify the token much faster. To invalidate the token you just need to remove it from the cache.

2. Use short-lived access and refresh token

This is mentioned in a lot of Security Submits. Expert says to set a very short life (in minutes) to both access and refresh tokens. Also, exchange the refresh token every time you get a new access token. This renewing process can be happing in the background (maybe using workers). So you don't need to invalidate tokens, It will be invalidated automatically after a few mins.

Recommend you to watch this: https://www.youtube.com/watch?v=rCkDE2me_qk

• Store your refresh tokens in a database, with enough context to create a new JWT token (also expiry date, allowed IPs/regions/browsers ...etc) this database will be used only by your Auth service, and only when managing auth (login, logout, refresh access token).
• Storing JWT in a database introduces a single point of failure for your microservices (Assuming you are using this architecture), if you're storing JWTs somewhere it would be a simpler implementation to just use session IDs and data.
• Give each JWT token an ID (it's already in the default claims), and link that ID to a refresh token
• when you invalidate a refresh token, broadcast an event to all your services telling them that any JWT with the token.JwtId is invalid. this invalidates all JWTs created by that token on all services (You can invalidate by token context as well, ex: user id to invalidate all tokens for a user that were created before X)