CDx Event

An Event is something that happens at a specific moment in time within a specific context.

SafeCDx treats every request, be it a command to change data in the platform or a query for information from the platform as an event. The events are called Spec Events. The Spec Event is an information payload that includes the request data payload along with multiple meta-data attributes regarding the request. SafeCDx services derive all the metadata for the Spec Event through the concept of progressive profiling.

When a request is made to a service in SafeCDx, it travels through multiple layers in the network. Every layer of the network adds to the Spec Event by enriching the metadata on the event. Some examples of the metadata are user, location, trace, device and the message producer information. This allows SafeCDx adapters to tap into the information that is paired with the request payload to make informed decisions by validating and responding to the requests appropriately.

A request’s profile is progressively enhanced at every step of the network layers through which it travels and allows the services to make decisions on security and consent and proceed. Data is encrypted in transit and at rest in SafeCDx. The services can then decrypt based on consent that can be derived by using the metadata on the Spec Event.

The SafeCDx Event flow describes how an API call for data mutation proceeds through the network. There are 4 stages through which the data passes. Each of the below stages are baked into the SafeCDx service design and implementation. These stages progressively enrich the Spec Event before the request reaches the service layer. The service then has access to all the Spec Event meta data which includes the request payload and a host of other attributes that can be used by the service. These stages can be viewed in both the mutation flow and query flow diagrams below.

Edge Cache: This stage determines the edge jurisdiction. It adds the geographic details of the request to the spec event. This information is useful in deciding consent based on geographic jurisdiction.

Ingress Gateway: The Ingress gateway handles global authentication for the request. This can be tuned with rules based on jurisdiction information obtained from the previous step in addition to the request.

Workload Proxy: The workload proxy is implemented using the Envoy proxy at the container level. The proxy handles the web application firewall, workload rate limiting and any security and privilege checks using the IAM module to determine access and consent for the incoming request. Any failures are handled at this layer and an error is returned to the client.

Workload: This is the service container that handles the data serialization and deserialization, data validation, spec interceptors and finally the command handler. The request then drops a spec event on the event plane, and immediately returns a response to the client. Any validation or data failures prompt the container to return an error to the client.