...
So, instead of ignoring this capability set, we will create it regardless of whether it partially includes some capabilities or lacks them entirely. However, all missing capabilities need to be recorded in the dummy capability ID mapping table so that we can resolve them in the future once they are created.
Now we have all the necessary information to update the capability set in the future, once the missing capability is created in the system.
...
We don't want to create a separate dummy capability set table since we will always create capability sets, regardless of whether they include all capabilities, only a partial set, or are empty.
If a capability does not exist, we will create a record in the dummy capability ID mapping table to resolve the relationship in the future.
Each time we create a new capability, we check the dummy capability ID mapping table to resolve any missing relations and run the update capability set method, which will create Keycloak resources and other necessary components.
The process of updating the capability set should be event-driven and need to use Kafka events instead of Spring events. This approach will help maintain data consistency in case the service crashes. (No need to an additional Kafka event does not is needed for version one and requires , but future versions will require additional design for the future to avoid the issues that we faced in the past.)
Delete the event and record in the dummy mapping table only when the capability set is fully updated
...