Open Software Design | Upmo

# 14. Comms as the primary data source for provider contacts (not Auth0)

  • Date: 2020-12-17
  • Driver: Wisen Tanasa
  • Contributor: Harsh S. Kulshrestha
  • Approver: Wisen Tanasa

# Status

Accepted

# Context

We are about to build a UI for entering provider contact information in the provider portal, therefore we need to understand who is the primary data source for provider contacts where we can save this information to. We do not have any single source of truth at the moment, and provider contact information are stored in separate places:

  • email addresses in viewing bounded context
  • phone numbers comms bounded context
  • identity information (which will include email address) in account / identity bounded countext for provider portal login in the future

The reason we ended like this in the first place is because we were not sure about which of these bounded context should be the primary data source. We had a couple of candidates that could be the root of the bounded contexts:

  • comms bounded context, as we think that all of these contact information we need is for communication purposes
  • identity bounded countext (Auth0), as this contact number could be perceived as just part of their identity
  • Create account data store that's managed by us.
  • And, NOT viewing bounded context, it feels wrong

# Decision

  • Comms bounded context to be the primary data source for contacts

# Consequences

Creating a new account data store that we manage by ourselves is too wasteful at this point of time, so we have ruled out that option. The options that we have left then is either to go down with comms or Auth0.

What we initially thought to be the best primary data source for contacts is Auth0 / identity. The first issue with Auth0 as the primary data source we'll have a technical risk of using a domain model (from Autho) that are not designed for what we need. Even though on the first glance an identity solution and contacts are storing similar data, they might not be the same in the future. There might be a requirement, for example, for us to ensure that there's only one primary contact for a building. Enforcing this invariant is difficult if we don't control the model, and will impede our speed of change.

Auth0 Management API also has 2 requests per second rate limit, which means we'll have a scalability issue when there are too many requests to Auth0. Although this could be mitigated by building a intermediary replica, it's not going to be cheap to be implemented. Worst of all, the solution may look too similar to what we'll do on comms service!

Making Auth0 as the primary data source will imply that all provider contacts will have an account, which doesn't necessarily hold true. It is a valid scenarios for contacts not to have accounts. We have a plan to eventually allow all provider contacts to login, but at this point we'll stick to YAGNI and decide on what we know.

The downside of using communication bounded context is it may seem to be too constraining in terms of how the contacts data should be used. It gives the impression that we're storing the contact data just for communication purposes. While we could actually use the information for something else, like authorization, we think that that would only cater for 20% of its usage. 80% of the data usage would be for communication purpose. Hence this is not a big downside.

Storing contacts information in comms-service will make it technically more difficult for provider contacts to update their own information as we'll have to hit Auth0 and comms-service from the webapp when they need to update their email-address (Auth0 + comms-service) and phone number (comms-service). Even if we will have this issue, we think that it's going to be quite straightforward to call two APIs; one additional call on top of what we already need which is Auth0. This API all could even be done on the Universal Login page despite the widget being owned by Auth0 (by configuring the Lock widget).

Last but not least, storing contacts information by ourselves would mean that we'll have to spend more effort to be GDPR compliant. We have deliberately made sure that we only store PII on Auth0 from the start as Auth0 is a GDPR compliant proven service that would naturally store PII (email address). To mitigate this, one of us has experienced making systems GDPR compliant, and we think that it's more important and not too costly for us to have a good process to delete provider contacts to be GDPR compliant - meaning even when we use Auth0, we'll have to implement this process. The important part here is to also make sure that we don't log PII as they're hard to be found and deleted - which is something that we have to do anyway when we hit Auth0. It's a extra small area to be taken care of.

←