A team is deciding between server-side sessions and JWTs for a new service that will eventually be called by several other internal services. What's the actual trade-off, and what does the JWT side give up that a naive "JWTs are stateless and therefore better" pitch misses?

The real question underneath "sessions or JWT" is whether the server remembers what it issued or only verifies what comes back. A session is an opaque id that's a key into server-side state — every request costs a lookup, but the server can change its mind at any time: revoke it, list active devices, force a logout. A JWT carries the facts and a signature, and any instance (or a different service entirely) can verify it with just a key, no lookup, no shared store — which is genuinely the right fit for the described case, multiple services verifying independently. What it gives up is the mirror image of what it gains: once issued, a JWT is valid until it expires, full stop, and "log out" becomes a client-side gesture — throwing the token away doesn't invalidate a copy taken beforehand. The usual answer that gets most of both is short-lived access tokens (minutes) plus a long-lived, server-recorded refresh token that actually can be revoked.