Payment Linked Loyalty – Under the Hood
Bink’s Payment Linked Loyalty service came about with the primary target of streamlining the customer journey, removing any friction from the customer’s experience of earning and redeeming loyalty rewards. The customer’s payment card becomes their loyalty card – through the simple act of paying they can earn their loyalty rewards every time, without a second thought.
The simplicity of the front-end solution, however, relies on a complex technical architecture, with reliability and scalability at its core.
For National Coding Week we wanted to move the spotlight to the (usually) unsung heroes that make sure that our technical infrastructure is always there to support the needs of the customers: the DevOps team.
The importance of what they do cannot be overstated, however, the very nature of their work makes it rather opaque for an average non-technical person to understand.
Luckily, our wonderful DevOps team took the time to explain it, and in the most engaging way possible: through a game. Digging deep into the geek-verse, they used the iconic 90s shooter Doom to demonstrate how our technical infrastructure is set up to make sure it copes with the demands of our Payment Linked Loyalty service.
By using Kubernetes (an open source container orchestration system for automating software deployment, scaling, and management) our DevOps team can set up automation that ensures reliability and scalability of our server architecture. That sounds pretty abstract for the non-initiated so they translated all that for us in a simple visual metaphor: every server is a monster in the Doom game.
If for whatever reason one server breaks down (i.e., if our enthusiastic demo-er takes a chainsaw to one of the monsters) another one will spawn, within a second of the first monster/server being killed, ensuring the end customer doesn’t notice any interruption to the service.
This demonstrated the resilience of the system. But what about scalability? What happens if we have an environment with tens of monster/servers, rather than three of them, and if we decide to replace the chainsaw with a rocket launcher?
To illustrate the scalability the Doom demo was programmed to increase the number of monster/servers and since the chainsaw was no longer fir for purpose, the rocket launcher came in and created mayhem.
Even in this more complex environment the resilience of our system showed that the result was always going to be Rocket launcher 0 – DevOps team 1.
It was great to get a first-hand experience of both the resilience of our system and the DevOps team’s creativity. We look forward to the next demo and wonder what they’ll come up with next? Super Mario disaster recovery? Bomberman pen testing?