Messaging Services

This document provides an overview of the Messaging Services.

Reference Documents

Reference	Document Location
PRD-MOBILE	PRD Mobile Notifications
PRD-EMAIL	PRD Email Notifications
IOS-PUSH	Push notifications in iOS
DIA	Diagram

Problem Description

We need a way to send human friendly messages, notifications and alerts to our users through different channels. The messages can be automatically triggered when something of interest to the users happens in our systems, they can also be manually triggered by our staff when Ebury needs to communicate something to the users.

Background

The mobile app will allow new means of communications with our users, one is push notifications. A push notification is an ephemeral message that exists only until the user reads it and is visible in the device message center with an optional alert. They allow us to send live operational updates, system status updates, and marketing directly to the user's devices. Push notifications also allow us to improve security, by alerting the user when a security related event happens to their account and by allowing us to implement new ways to perform multi-factor authentication.

Other communication channels apart from push notifications can be sms messages and emails. The Messaging Services need to support them, and also be extendable to support other channels if needed.

The messages and notifications that are sent through the supported channels can be triggered in two ways: - Manually, through an admin tool that allows Ebury personnel to send those communications to the users. - Automatically, by integrating with backend services.

Solution

We propose the creation of an ecosystem of small services called Messaging Services, which will be responsible for integrating our systems with the third party notification providers.

Architecture

The following diagram is a high-level overview of the proposed solution.

Notification Providers

The Notification Providers are the third party services that do the actual delivery of the notifications. Some examples of notification providers are Firebase Cloud Messaging, Twilio or SendGrid.

Notifications Gateway

The Notifications Gateway is the core of the Messaging Services. Connects our backend services with the Notification Providers and performs any transformations needed to get the messages sent. It can delegate part of its responsibilities to an external third party service.

Provides the following functionality: - Notification persistence. - Contact details persistence for each recipient and channel. - Notification settings persistence for each recipient. - Notification expiration. - User grouping by client, brand, region. - Optional notification rendering in the right language using templates.

Subscriber Manager

The Subscriber Manager is a connector between the Ebury backend service that is the source of truth for user contact information and the Notifications Gateway.

This service is responsible for consuming contact and client related domain events and create or update the subscriber (user) contact information in the Notifications Gateway. The service will also keep the different user groups updated, assigning or removing the users from them.

Some of the fields that need to be saved in the provider are: - Contact ID - Email address - Phone number - Language - Brand - Clients - Region

Messaging Public API

This is an API exposed as part of Ebury's public API. It's responsibilities are: - Allow submission of FCM tokens from mobile devices or web applications to enable push notifications. - Expose messaging settings management endpoints. - Expose endpoints to allow users to access their inbox.

All the endpoints will require authentication and will be protected by the same mechanisms that the Public API uses.

Message Generation

The messages are sent directly from the different backend services through the Notification Gateway using a client library.

iOS Frontend

In the case of the iOS application it will receive the notifications through Apple Push Notification Service (APNS), which is a service provided by Apple for sending push notifications to iOS devices even when the app is not currently active on the device. APNS needs to be integrated into the app.

The app will need to register itself for notifications in APNS and FCM, submitting its FCM token to the backend. The complete flow is documented in the IOS-PUSH document.

Push notifications are not guaranteed to arrive, so it is not recommended to use them as the only way of delivering content. Instead, push notifications should signal that there is new content available and let the app download the content from the source (the Messaging Public API) which we have as a second option of informing the user of the app.

Service Ownership

New Service	Service Name	Service Owner
Yes	Subscriber Manager	MOB Team
Yes	Notifications Gateway	MOB Team
No	Messaging Public API	MOB Team
No	API WebApp Proxy	MOB Team
No	API Gateway	MOB Team

Alternatives

We could implement the functionality in each individual service that needs to send messages or notifications, but that is wasteful since we would be implementing the same functionality over and over again. Harder to maintain and harder to track notification systems usage.

Caveats

If we decide to use a third party messaging service the main caveat are recurring costs, which are high for a service that meets our functional, compliance and support requirements. This ca be avoided by connecting our gateway directly to the third party channel services.

Operation

The services will run in Kubernetes using the following network areas:

Service	Network area
Notifications Gateway	publicfrontal
Messaging Public API	publicfrontal
Subscriber Manager	internalservices

Security Impact

The new service will expose new APIs through the Public API and the Gateway. User authentication for these APIs will be leveraged to the existing API Auth. Secrets will be stored in Vault and service to service communication will be authenticated using pre-shared access keys.

Regarding user information the service will store some user details like language, region, email and phone number, also the messages generated by the service may contain in some cases user information, for example the money amount for a transaction.

Performance Impact

The service should not have a performance impact on any of the backoffice services, but it will add new event consumers that increase the load of the Kafka clusters. Regarding the Kubernetes clusters the new services will consume resources from them, which may require our Platform Team to increase the resources of the cluster. Last, the new functionality provided by the service may increase slightly the amount of requests that our public API receives.

Developer Impact

We don't expect any immediate developer impact. When the service is complete developers will have an additional tool to add messaging functionality to their services.

Data Contracts

We don't expect to create new data sources or amend existing ones.

Data Sources

The service will source its data from: - BOS client and contact domain events, needed to know user details like language.

Output data: - Logs recording system operation. - API exposing user messaging configuration. - API exposing messages. - Requests with message contents to the third party providers.

Deployment

The services will be deployed using the standard pipelines and procedures already in place.

Dependencies

We haven't identified any dependencies.

Based on RFC Template Version 1.1