Deze grote pensioenuitvoerder heeft een grote hoeveelheid externe partijen waarmee zij communiceert. Als spin in het web draagt zij zorg voor het verzamelen, verrijken en versturen van de juiste informatie. De correctheid van berichten en of deze op de juiste manier zijn afgeleverd, zelfs bij een niet beschikbare doelapplicatie, zijn hierin van groot belang. In de oude on premises situatie werd op maandbasis gewerkt met enorme batches aan data. Hierdoor duurde de processen lang en was de data altijd verouderd.
Om gebruik te kunnen maken van maximale schaling en de kosten zoveel mogelijk te beperken, werd het werkgeversportaal (webapplicatie) met alle datavoorziening en integratie, gemigreerd naar Azure. De grote en dure on premises SQL webservers werden vervangen door scale-when-we-need componenten zoals Cosmos DB, web API’s gebouwd in Azure functions en Azure SQL. Dit resulteerde in hogere doorvoersnelheid en lagere kosten. Omdat het proces in de nieuwe situatie sneller klaar is, is het niet langer gebonden aan weekendverwerking maar kunnen er vaker batches draaien en krijgen de web portals vernieuwde data.
De informatiestromen zijn opgesplitst in twee typen, namelijk: synchrone en asynchrone data. Voor het lezen van data wordt synchrone data gebruikt. Dit wordt door Azure Functions met een web API ontsloten uit verschillende databronnen. Hoewel de data mogelijk gestaged en (licht) verouderd is door batchverwerking, krijgt de aanvrager (cloud web portals) wel direct resultaat.
De asynchrone verwerking wordt gebruikt voor processen waarbij het van belang is dat de informatiestroom volledig wordt uitgevoerd. Requests worden op een queue gezet en in een separaat proces opgepakt en verwerkt. Lukt de verwerking niet, gaat het bericht terug de queue in en wordt het later opnieuw geprobeerd, net zolang tot het gewenste resultaat is behaald. Blijkt er iets mis met het bericht, wordt deze apart gezet en krijgt operations een notificatie om het probleem te onderzoeken. Voorheen moesten deze berichten via complexe methoden opnieuw worden verstuurd vanuit bronsystemen, wat tijdrovend of onmogelijk was.
De eerste processen zijn omgezet in het nieuwe format. Door de schalingsmogelijkheden van de serverless componenten is de doorlooptijd in veel gevallen uren korter, is de hoeveelheid (handmatige) correcties geminimaliseerd en zijn de oude nog overgebleven fragiele on premises services beschermd met rate limiting vanuit Azure API Management om overbelasting te voorkomen.