De Stadsbank levert een dienst die lijkt op die van een pandjeshuis: klanten kunnen één of meer voorwerpen belenen (ook wel ‘pandjes’ genoemd) in ruil tegen een geldsom. En zo start het leenproces, met als einddoel om de klant het geleende geld terug te laten betalen in ruil voor het beleende item. De Stadsbank is onderdeel van de Gemeente Amsterdam, wat betekent dat het geen winstoogmerk heeft. In de loop der jaren hebben zo’n 90.000 klanten zo’n 900.000 items in onderpand gegeven. Om hun core business, het bijhouden van alle klanten en hun pandjes, goed uit te kunnen voeren maakt de Stadsbank gebruik van data. Denk hierbij aan data over afzonderlijke kassa’s, betalingen en andere financiële transacties.

Al met al een behoorlijke hoeveelheid data dus, die in het nieuwe systeem zowel toegankelijk als bruikbaar moet zijn. Het migreren van zulke enorme hoeveelheden data brengt een aantal uitdagingen met zich mee:

• We bouwen niet alleen de applicatie om, maar hun datamodel als geheel. Door de nieuwe wet- en regelgevingen is het onvermijdelijk om de data (in meer of mindere mate) te transformeren.
• Aangezien we met financiële gegevens werken is data-integriteit van cruciaal belang.
• De uiteindelijke migratie zou een ‘big bang’ worden, wat betekent dat de transitie van het oude naar het nieuwe systeem ineens gebeurt in plaats van geleidelijk. Daarbij wordt het huidige systeem nog actief gebruikt en hebben we dus maar één kans om alles in één keer te migreren, zodat het systeem meteen gebruikt kan worden.

Er waren dus twee vragen die we moesten beantwoorden:

1. Hoe gaan we het migreren van deze data aanpakken?
2. Hoe kunnen we de integriteit van deze data garanderen?

De voorbereiding

Laten we beginnen met hoe we de migratie aangepakt hebben. Bij de bouw van een applicatie is één van de dingen die lastig kan zijn het gebrek aan beschikbare testdata. Gelukkig hadden we een complete dataset om te migreren, wat betekent dat we tijdens de development-fase meer representatieve testen konden uitvoeren. We wisten toen nog niet hoe ons uiteindelijke datamodel eruit zou komen te zien, dus daarom migreerden we alleen de data die we nodig hadden voor het implementeren van onze stories. Zo wisten we zeker dat we onze database niet zouden vervuilen met data die niet gebruikt werd.

Elke ochtend maakt de Stadsbank een datadump die wij vervolgens om 8:00u in onze omgeving importeerden. Zo hoefden we ons geen zorgen te maken over open verbindingen, terwijl we zelf makkelijk en snel door de data konden browsen. Iets dat toch wel erg handig is bij het ombouwen van een datamodel.

Verder concludeerden we dat de transformaties die wij gebruikten behoorlijk ingrijpend konden zijn. Daarom hebben we een aparte service gemaakt speciaal voor het migreren van gegevens van de gekopieerde database naar de nieuwe database die door de nieuwe applicatie zou worden gebruikt. De resulterende architectuur zag er zo uit:

Migraties uitvoeren

Om mogelijke problemen met onze data mapping zo snel mogelijk te identificeren, besloten we om elke nacht vanaf 00:00u migraties uit te voeren. In de eerste instantie migreerden we alleen kleine datasets (zoals klantnamen), maar later begonnen we ook meer data voor de nieuwe functionaliteiten te migreren. Daarom duurde de migratie langer naarmate de tijd vorderde, in plaats van korter. Uiteindelijk liepen we er tegenaan dat onze migraties niet snel genoeg uitgevoerd werden; aangezien we de dataset alweer om 8u moesten importeren, hadden we maar acht uur om de migratie af te ronden, omdat de migratieservice anders zou crashen. Dit betekende dat we meer tijd moesten investeren in het werkbaar (en minder zwaar) maken van onze migraties. Om dit mogelijk te maken hebben we een paar dingen gedaan:

Native queries gebruikt
Onze migratieservice was een Spring Boot-service die aanvankelijk gebruik maakte van JPA en Hibernate. Allebei deze libraries maken developen een stuk makkelijker, maar kunnen de performance ook beïnvloeden, omdat er zoveel gebeurt op de achtergrond. Daarom hebben we besloten ze te verwijderen en ons vooral te richten op native queries.

Statische data geïdentificeerd
Een deel van de data die we nodig hadden voor de migratie was heel statisch: data zoals de verschillende kenmerken die artikelen kunnen hebben, was onveranderlijk, maar vertegenwoordigde desalniettemin een behoorlijk stuk. Door deze data slechts één keer te migreren – en dus niet elke nacht opnieuw – hebben we flink wat tijd bespaard.

Gelijktijdigheid geïntroduceerd
Dit was makkelijker gezegd dan gedaan, aangezien de meeste van de data enorm afhankelijk van elkaar zijn. Echter, naarmate de tijd vorderde, identificeerden we steeds meer data die gelijktijdig gemigreerd kon worden. Dit bespaarde ook tijd.

Door deze bovengenoemde stappen te doorlopen hebben we onze migratietijd weten te reduceren tot zes uur!

Voorbereiden op de volgende migratie

Uiteindelijk is het ons gelukt om alles naar tevredenheid af te ronden. Er zijn een paar learnings die wij tijdens dit proces hebben opgepikt en die wij persoonlijk vanaf nu bij elke migratie meenemen. We willen ze graag met jullie delen:

1. Wees selectief in wat je migreert. Bij het uitvoeren van een datamigratie is het van het grootste belang dat je weet welke data je wel en niet gaat migreren. Als je een migratie meerdere keren uitvoert, raden we je aan om de data te identificeren die statisch genoeg is om eenmalig te importeren.
2. Migreer zo vaak mogelijk. Iets dat voor ons enorm waardevol is gebleken, is het zo vroeg mogelijk starten met migreren. Dat begon bij ons al tijdens de eerste sprint. Hierdoor wisten we hoe we op de oude data moesten anticiperen, hadden we altijd beschikking over testdata en – niet geheel onbelangrijk – hadden we de zekerheid dat onze migratie zo soepel als mogelijk zou verlopen.

Dit gezegd hebbende is het migreren van de data slechts het halve werk. In dit blog heb ik enkel besproken hoe je het migreren van data het beste kunt benaderen, maar ben ik nog niet verder ingegaan op hoe we konden garanderen dat deze migratie goed zou verlopen. Dat is een verhaal (of blogpost) voor een volgende keer.

Als je wil weten wat we precies gedaan hebben voor de Stadsbank van Lening, bekijk dan hier de case study.