Speaker: Alan Reyes Vilchis, Technical Lead, Banco Azteca Level: 200 (Intermediate) Track: Developer Business apps powered by single customer views (SCV’s) are one of the most predominant uses of MongoDB. However, each view presents unique challenges such as distilling data from providers, removing duplication, matching records in different systems, and more. The team at Banco Azteca (part of Grupo Salinas, a holding company of enterprises in media, telecommunications and financial services) in Mexico City has launched various customer-centric banking services that are powered by an SCV built on MongoDB, which has not only allowed the expansion into mobile-first consumer markets, but has also helped in identifying and preventing fraud across the group’s enterprises. This talk will explore the overall initiative, and place emphasis on the technical innovations regarding design, serialization and transactions across multiple systems. What You Will Learn: - “Serialization magic” using the MongoDB Java driver and Jackson - Implementing transactional-like logic across different systems - Conceptual and physical design for building a Single-View

1. A Customer-Centric
Banking Platform Powered
by MongoDBAlan Reyes Vilchis
Technical Lead, Customer 360

2. Customer 360 Development Area
Customer 360 was born with MongoDB
adoption at Banco Azteca
Our objective is to build a customer-centric
services platform to be used by all of the
companies of the group

3. Grupo Elektra

4. Banco Azteca
Banco Azteca is changing its way to relate with the
Customers, under the motto:
“Everything that you can do in a branch,
you can do it in our app”
To achieve this objective we needed to review our
workflows

5. Before Platform 360
Branch
Unique
Customer
Banking Core Loans
App
Backend

6. After Platform 360
Platform 360
Branch
App
Backend
Unique
Customer
Banking
Core
Loans
Services

7. What are we building?
Digital Mobile Bank
iOS
Application
Android
Application
Application
Backend
Customer 360
Single View
System of
Record

8. Customer 360
Single View

9. Money Exchange before the Single View
Money Exchange
at branch
Banking
Core
Unique
Customer
Money Exchange
own database
The identification of customer required searches to different systems, using
different contracts and capabilities for each one of them

10. Money Exchange after the Single View
Money Exchange
at branch
Customer 360
Single View
The identification of customers can be done now in a single search, retrieving
results with the same or better quality

11. Single View Design
Person
Master
Sources
UC_1-1-1-1
ALNOVA_12345678
UC_1-3-20-12
LOANS_1-1-1-1
Structure of a Person’s Record on the single view:

12. Single View
Single View Data Flow
Banking Core
MS SQL Server
Unique Customer
Oracle
Loans
AS400
REST API
Unified Database
Talend
Talend

13. Scop
e
Business
Benefits
Transactions are written first to the single view, which
propagates the data back to the source system of record.
Writes are performed concurrently to the source systems as
well as the single view
The single view data model is enriched with additional
sources to serve more applications, including real-time
analytics. The single view becomes a platform serving
multiple applications
Single View
Platform
Records are copied via ETL or message queue
mechanisms from the source systems into the single view,
serving read queries. The single view serves one specific
application
Single View
Application
Single View
First
Dual Writes
Read
Centric
Transforming the role of
the single view
Reads & Writes
Single View Maturity Model
https://www.mongodb.com/blog/post/10-step-methodology-to-creating-a-single-view-of-
your-business-part-3

14. Architecture for Writes to the Single View
ETLorMessageQueue
Web
Mobile
CRM
Mainframe
Single View Call Center
Analytics
Technical
Support
Billing
Update
Queue
Reads
Writes
Source Systems Consuming Systems
Load
https://www.mongodb.com/blog/post/10-step-methodology-to-creating-a-single-view-of-
your-business-part-3

15. System of Record

16. • New business logic and constraints for our new
mobile-first use cases
• Unique Customer didn’t allow to register
anonymous customers
• Need to manage the customers of new
businesses without requiring them to have their
own databases
Why was it needed?

17. Design of the System of Record
Structure of a Customer Record
Customer
Personal Data
Business
Extended A
Business
Extended B
Business
Extended C
(Virtual)

18. System of Record Data Flow
Unique Customer
Oracle
System of Record
REST API
Database Banking Core
MS SQL Server

19. Main technologies

20. • Horizontal scaling
• It’s flexible schema allows us to
– Reduce the development time in half, by integrating
the development work on the database and the
application
– Keep related objects with variable schemas together in
the same collection or array
MongoDB

21. Java
• Enterprise trusted
• Strong typing
• Plenty of libraries

22. Technical challenges

23. Integration of customer data
ID: 1
Name: John Smith
ID: 2
Username: jsmith
ID: 1
Name: John Smith
Username: jsmith
ID: 2
Primary: 1

24. Solution on a Relational Database
CustomerPrima
rycustomer_id
primary_id
CustomerData
customer_id
name
username
CustomerId
customer_id

25. Solution on MongoDB
{
"id": 1,
"name": "John Smith"
}
{
"id": 1,
"name": "John",
"username": "jsmith"
}
{
"id": 2,
"principal": 1
}
{
"id": 2,
"username": "jsmith"
}

26. Keep related objects together
Unique Customer ID
channel: 1
branch: 13
id: 87
Alnova ID
id_alnova: 1
Unique Customer ID
channel: 2
branch: 23
id: 54
Customer

27. Solution
CustomerLinkedUniqueCustom
er
customer_id
channel
branch
id
CustomerLinkedAlnova
customer_id
alnova_id
Customer
customer_id
{
"id": 1,
"linked_ids": [
{
"origin": "bank",
"id": {
"bank_id": 1
}
},
{
"origin": "branch",
"id": {
"channel": 1,
"branch": 13,
"id": 87
}
},
{
"origin": "branch",
"id": {
"channel": 2,
"branch": 23,
"id": 54
}
}
]
}
VS

28. Integration of Java and MongoDB

29. Technologies stack
MongoDB
Native Java
Driver
MongoJack
Jackson
Value.Immutabl
e

30. Output:
Value.Immutables
Creates immutable implementations based on a contract

31. Output:
Value.Immutables
Immutables enforces consistency

32. Jackson
@Value.Immutable
interface Customer {
@JsonProperty("_id")
int getId();
@JsonProperty("first_name")
String getFirstName();
@JsonProperty("last_name")
String getLastName();
}
{
"_id": 1,
"name": "JOHN",
"first_name": "SMITH",
"last_name": "SMITH"
}

33. Jackson Mixin support
// Data Class
class Data {
String property;
String getProperty() {
return this.property;
}
String setProperty() {
tis.property = value;
}
}
Jackson
ObjectMapper
Data
instance
JSON
// Annotated Contract
interface DataMixin {
@JsonProperty("property")
String getProperty();
}

34. MongoJack
Customer
MongoDB
Collection
JacksonCollection (MongoJack)
ObjectMapper (Jackson)
MongoJack Module
MongoDB Java Driver
DBObject

35. Common Library
Customer Class
Reusability
Customer
instance
JacksonCollection (MongoJack)
ObjectMapper (Jackson)
MongoJack
Module
JSON
HTTP API (Jersey Server)
ObjectMapper (Jackson)
MongoDB
Collection
HTTP Client (Jersey Client)
ObjectMapper (Jackson) Customer
object

36. Distributed transactions

37. Current Model
Customer
Extended A
Customer
Extended B
Customer
Customer Model
addAddress()
setName()
addLinkedId()
beginModify()
commit()
Controller

38. Proposed Model
Transaction
Actions
apply()
SetNameAction
AddLinkedIdActio
n
AddAddressAction
Customer
Extended A
Customer
Extended B
Customer
Controller
Action
prevalidate()
apply()
notify()

39. Transaction flow
Transaction
Prevalidation
Application
Notification External
services
Database

40. Summing up

41. Summary
To sum up, I showed you:
• How we have build our single view
• How we have build our system of record
• How we used MongoJack, Jackson and
Value.Immutables to map Java objects to MongoDB and
back
• How we designed a framework to apply complex
transactions

42. Thank you!
On behalf of the
Customer 360 Development Team

43. Q & A
Alan Reyes
Vilchis
Technical Lead,
Customer 360
@KuttKatrea
Font Awesome by Dave Gandy - http://fontawesome.io