In a well-designed microservice system, exception and success classification must be consistent, traceable, and informative. Below is a complete reference list organized by type and mapped to HTTP status codes. Each exception or success type reflects its purpose: successful operations (2xx), client errors (4xx), or server errors (5xx).
✅ 1. Success Response Types → HTTP 2xx
| Identifier | Meaning | HTTP Code |
|---|---|---|
UserRegisteredSuccessfully | New user was created successfully | 201 |
LoginSuccess | Login completed and tokens issued | 200 |
LogoutSuccess | Token revoked/logged out | 200 |
TokenRefreshed | Access/refresh tokens issued | 200 |
TokenStored | Token saved successfully | 200 |
TokenDeleted | Token deleted successfully | 200 |
UserDeleted | User account removed successfully | 200 |
EmailAvailable | Email is free for registration | 200 |
ProfileUpdated | Profile details updated | 200 |
⚠️ 2. Domain-Specific Exceptions → HTTP 4xx
(Client-side problems: validation, auth, bad data)
| Exception Class | Meaning | HTTP Code |
|---|---|---|
UserNotFoundException | User ID/email not found | 404 |
DuplicateException | Email already exists during registration | 409 |
TokenExpiredException | Token provided by client has expired | 401 |
InvalidTokenException | Token format or signature is invalid | 401 |
InvalidInputFormatException | Request body malformed or fails validation | 400 |
InvalidEmailFormatException | Email does not follow pattern | 400 |
UnsupportedMediaTypeException | Request content-type not accepted | 415 |
GoogleIdTokenInvalidException | Google token invalid or does not match expected user | 401 |
💥 3. Domain-Specific Exceptions → HTTP 5xx
(Server-side failures: internal, upstream, logic failure)
| Exception Class | Meaning | HTTP Code |
|---|---|---|
TokenSaveFailedException | Failed to store token in DB | 500 |
MemberServiceException | Failed when calling member microservice | 500 |
TokenDeletionException | Failed to revoke/delete token | 500 |
TokenNotFoundException | Unexpected error fetching token | 500 |
ServiceDependencyFailureException | Upstream service returned error or timeout | 503 |
JwtGenerationException | Failed to generate JWT token | 500 |
UnknownServerErrorException | Fallback for unhandled RuntimeExceptions | 500 |
✅ Priority Order for Exception Handling in createUser
1. 🛠️ MemberServiceException (Dependency Failure)
Why first?
If themember-serviceis unavailable, unreachable, or throws a 5xx error,
there’s no point in validating domain rules — nothing else can proceed.Examples: service down, timeout, internal error in member-service.
HTTP:
500
2. 🔐 Domain-Specific 4xx Errors (Client Validation & Business Rules)
Why second?
Once the member-service responds successfully, domain rules must be
enforced (e.g., duplicate email, invalid tokens).Handled by: your own microservice logic or parsed from the response body.
Examples:
DuplicateExceptionGoogleIdTokenInvalidExceptionInvalidEmailFormatException
HTTP:
400–409
3. 🧨 UnknownServerErrorException or generic RuntimeException
Why last?
This is a fallback for logic bugs or uncaught exceptions. It ensures you never
expose stack traces or generic error messages to the client.Handled by: global
@ControllerAdviceHTTP:
500
🔁 Flow Visualization
verifyGoogleToken()
↓
call member-service (email check / register)
↓
| If fails → MemberServiceException |
↓
validate duplication, Google token match
↓
| If fails → Domain-specific 4xx errors |
↓
proceed to token issuance/storage
↓
| If fails → TokenSaveFailedException or UnknownServerErrorException |
↓
return 201 Created with tokens
Let me know if you want to:
Add controller advice mappings for these
Convert this into an enum/error registry system
Integrate this with Swagger OpenAPI annotations
Map each exception with a unique error code (e.g.,
M101,A203)
