The document outlines the implementation of a key payment processing system running on a MariaDB Galera cluster at CCV, detailing their transition from existing SQL Server and DB2 platforms. It includes specifications for database architectures, disaster recovery requirements, and issues faced during proof of concept, emphasizing the need for scalability and near-zero downtime. Key personnel and their expertise are highlighted, along with system design, testing environments, and integration with other CCV systems.

1. Key payment processing system
running on MariaDB Galera Cluster

2. Introduction
March 7, 2019 2
Harry Dijkstra
Senior Database Specialist
• 18 years experience in Oracle databases
• 2 years experience in DB2 and SQL Server
databases
• 3 years MariaDB experience
Ernst Wernicke
Senior Database and Storage Specialist
• Over 15 years experience in DB2, SQL Server and
Oracle databases
• Over 15 years experience in payment processing
systems
• 3 years MariaDB experience

3. CCV Processing
• Arnhem based
• Family owned
• 60 years old
• Payment processor
– Retail
– Parking
– Petrol
– Travel & Entertainment
• Loyalty provider
March 7, 2019 3

4. CCV @home in Europe
March 7, 2019 4

5. Fact & Figures
1.100
Employees
€ 190
Mio.
Revenue
220.000
Customers
+770 Mio.
Transactions
15.000
Webshops
600.000
Terminals
(touch points)
CCV Group

6. Presence CCV Easy solutions
6
Including local scheme (if applicable)
Only for international brands
No presence yet, but on target
list
March 7, 2019

7. Databases@CCV
March 7, 2019 7
• MariaDB
– private cloud
– future processing platform
– strategic future choice
• SQL server
– current processing platform
• DB2
– current back-office
• Oracle
– limited installed base

8. MariaDB@CCV
March 7, 2019 8
• CCV360
– Development of a new, omni-channel portfolio
– Terminal, cash-register app, webshop, loyalty,
merchant boarding and MyCCV
• jSwitch
– Operational 2021
– Future processing system

9. jSwitch@CCV
• Requirements
• Database architectures
• PoC
• Issues, considerations and discussions
• Next steps
• Realization
March 7, 2019 9

10. jSwitch Requirements summary
March 7, 2019 10
• Two geographical sites
• No SPOF at any level
• System must be scalable to be future proof
• Max 3 sec. data loss during disaster
• 4000 database transactions per second (min 2 hours)
– Upscaling to 12000
• Near zero downtime (planned and unplanned)

11. Considered architectures scenario A
March 7, 2019 11
• Asynchronous connection between datacenters.

12. Considered architectures scenario B
March 7, 2019 12
• Preferred configuration, but requires a third datacenter, third datacenter is
out-of-scope.

13. Considered architectures scenario B’
March 7, 2019 13
• Evolved from scenario B.
• No third datacenter.
• Nodes@DC2 needs human action to continue processing when DC1 is out.

14. Considered architectures C
March 7, 2019 14
• Asynchronous connection between datacenters.
• Semi-sync within datacenters
• Possible more than 3 sec. data loss

15. Considered architectures scenario D
March 7, 2019 15
• Cross datacenter latency
• Possible more than 3 sec. data loss

16. jSwitch Database Architecture 2
March 7, 2019 16
• 5 node Galera cluster doing all transaction
processing
• In DC1 and in DC2 an asynchronous
intermediate master to offload data for
– offside monitoring,
– reporting,
– ad-hoc queries and
– backup.

17. jSwitch Database Architecture 1
March 7, 2019 17

18. jSwitch High level design
March 7, 2019
18

19. jSwitch PoC
March 7, 2019 19
• 5 node Galera cluster, stretched over 2
datacenters
• Asynchronous slave in DC1 and DC2
• X-86 Hardware
– Bare metal, no virtualization
– Local storage
– 256GB RAM
– 1 cpu 6 cores HT 3.6 Ghz
• Maxscale at all application servers

20. Issues, considerations and discussions
March 7, 2019 20
• Issues & discussions:
– Periodical performance drops
– 5 node Galera performance problems
– Open source
– Support or no support
– Enterprise vs non-enterprise
– Small installed base (especially in The Netherlands)
– External support/consultancy hard to find
• Pros:
– Solid database solution
– Full support from MariaDB
– Short lines to MariaDB support and developers
– Fast and adequate support from account manager
• PoC Outcome: Go

21. Next steps
March 7, 2019 21
• Building test environment
• Building acceptance and production environment
• Automation
• Fault tolerant
• Monitoring using Monyog
• Sharding
– Logical
– Spyder

22. Realization Test
March 7, 2019 22
• 3 Teams
• 9 environments
• Automation – Ansible
• Discussion technical concepts
• Discussion responsibilities
• First real world transaction

23. Realization Acceptance and Production
March 7, 2019 23
• Migration path
• Building Accp environment
• Connection to other CCV systems
– Fraud detection
– Front - Back office
– MQ Services
– Ewacs alerting
– Other shared services

24. Questions?
March 7, 2019 24
h.dijkstra@nl.ccv.eu
e.wernicke@nl.ccv.eu