Repository navigation
Best practice for User Provisioning between Microservice DB and Keycloak in a DDD/Hexagonal Architecture #45914
Replies: 1 comment
|
Hi, I think your idea of using an infrastructure adapter is reasonable, especially since you're already following Hexagonal Architecture. I would keep the Keycloak integration behind a port in your application layer, with an infrastructure adapter responsible for calling the Keycloak Admin API. That keeps the domain independent of Keycloak-specific implementation details. The bigger concern is consistency between PostgreSQL and Keycloak. A regular database transaction cannot atomically commit changes to PostgreSQL and an external Keycloak API. If the database operation succeeds but the Keycloak request fails, you could end up with a customer who cannot log in. For an asynchronous registration process, I would consider this approach:
The important part is making provisioning idempotent. For example, if the Keycloak request succeeds but the worker crashes before updating PostgreSQL, a retry should reconcile the existing identity rather than create a duplicate. Regarding which service should consume the event, I'd keep it within the customer service if identity provisioning is part of that service's responsibility. A separate identity-provisioning service makes more sense if multiple domains need the same capability. The BFF would not be my first choice for owning this process. So yes, an infrastructure adapter is appropriate, and the Transactional Outbox Pattern is a good fit if eventual consistency is acceptable for your registration flow. The remaining design decision is whether a newly registered customer can stay in PENDING temporarily, or whether your business requirements need immediate registration success or failure. |
Uh oh!
There was an error while loading. Please reload this page.
I'm building a microservices system using Java Spring Boot, DDD, and Hexagonal Architecture.
Current Stack:
BFF Service: Orchestrates frontend requests.
Customer Service: Manages domain-specific data in PostgreSQL.
Keycloak: Handles Authentication and Identity. (Authorization Service)
The Problem: When a new customer registers, I need to:
Here is CreateCustomerUseCase:
I am struggling with the most robust way to sync these two. I considered an event-driven approach where customer-service publishes a CustomerCreated event, but I'm unsure who should consume it to talk to Keycloak's Admin API.
Questions:
1-) Is it a good practice to handle Keycloak provisioning inside an Infrastructure Adapter in the customer-service itself?
2-) How do I ensure Data Consistency if Keycloak is down during registration? Should I use the Transactional Outbox Pattern?
All reactions