Skip to main content

Mobile Change Email Flow

Below is our current view of the change email flow for mobile. This does not identify any of the underlying architecture but we will go over them at each step.

Flow​

  1. A customer changes their email via Hybris.
  2. Hybris calls the api-customer-environment API Gateway sending a POST to the /update-email endpoint.
  3. The API Gateway has a lambda proxy to the api-environment-api-customer-emailUpdate lambda.
  4. The emailUpdate handler first checks if the email update is from a RCC Customer.
    1. If true the request is passed onto the environment-customer-sqs.
    2. The SQS triggers the rides-sync-user-email-environment-updateUserEmail lambda.
      1. The lambda maps through records from SQS. It processes them to see they have basic properties such as customerId, userId, newEmail and isRCC.
        1. If the record is missing properties or the customer is not RCC it will return an error.
      2. If the record is valid it update the user email in RDS via Prisma. This process is async so nothing is returned.
  5. The lambda then sends an emailUpdateEvent to exponea.
    1. If the update is successful we send a 200 back to the API Gateway.
    2. If the update is not successful we either send.
      1. 429 HTTP Error. This indicates the client (Exponea) has surpassed its rate limit or number of requests for a given period of time.
      2. 500 HTTP Error. This is an Internal Server Error.

Option 1

Resoureces​