No problem. It might not seem obvious when you build small-mid size backends, because in that scenario you might have an access token stored in your database that's checked each time someone makes a request. Token revocation is as easy as deleting that access token from your database.
Once you start building something at scale, it's harder to revoke tokens instantly. You still need to validate the token on each request, you need to build a highly available, fault tolerant system that can scale with the load of the rest of your application. Usually to reduce this load and improve performance, you'll see two strategies to deal with it:
Caching - check for the access token on the first request, and cache the access token for a certain period of time.
Signed / Encrypted tokens - JWTs are one example. The token contains the user ID, expiration, and other info, and is signed / encrypted. A server can read this, and knowing the signing key, verify the token.
However, if you revoke one of these tokens, it's not instant. A centralized store won't update any of the caches, and a Signed / Encrypted token lives on the client. So for token revocation, you now need to create a cache invalidation scheme, or maintain a blacklist of signed tokens.
While it's still not that hard, it'd hard enough that most teams would rather work on a new feature or something else that's on fire than figuring out token revocation.