Products
Solutions
Full Stack Icon
Online Payments
Full Stack Icon
Full stack payments
Full Stack Icon
Payment gateway
Products
Product icon
Payment links
Product icon
Fraud prevention
Product icon
Reporting
Product icon
Authentication
Developers
Online payments icon
Developers

Integrate and update your payments.

Documentation

Mobile SDK
Web SDK
Upgrade to 3D Secure 2
Sandbox testing

Developer Hub

Explore Hub
Engineering blogs
Comms archive
Online payments icon
Support Centre
Online payments icon
API reference
Online payments icon
Changelog
Online payments icon
Status Page
Company
AboutCustomersBlogCareers
PartnersPricingSupportLoginGet in touch
SupportLogin
Get in touch

#2 Creating Judopay's Next-Gen Tech Platform

Following on from our inaugural engineering blog, #1:  Challenging the Status Quo in Tech, I thought I would introduce you to some of Judopay’s engineering team, to talk about their journey in creating their next-gen tech platform:

‍

David Pollock, Head of Infrastructure and Automation Engineering

I have been with Judopay for over 6 years now, and have over 15 years of experience in the IT industry.  I’m passionate about building reliable, scalable systems and reducing toil with automation.

‍

Philip Keen, Senior Software Engineer

This is my fifth year of working for Judopay. I’ve been a software engineer for just over 10 years.

‍

James Patey, Senior Software Engineer

I have been with Judopay for 4 years now, with over 15 years working as a software engineer. I’ve long had a strong interest in building scalable systems, and learning new technologies along the way.

‍

As we mentioned in our inaugural blog Challenging the Status Quo in Tech, we are proud to have built a next-gen payments platform, running exclusively on cloud native principles. This enables Judopay to process our customers' payments with:

Peerless performance and scale‍‍,
Whatever their volumes‍‍
Any time of day.

Considering this ambition, our engineering team is lean. Every single member of our team is capable of making significant contributions to our goals. Operating with such limited resources presents not only a challenge, but also a great opportunity in forcing us to optimise our processes and focus on building features in order to provide the biggest value to our customers.

Like many engineering teams, we were faced with an outdated and struggling system, which was not designed for the needs of our business today and was beginning to impede our release agility.

So, to comprehensively address this, we have been going through a process of rebuilding our core systems onto a new tech stack. By embracing the advances in cloud platforms and more modern microservice architectures, to deliver a next-gen payment platform as part of our Sho~dan programme.

As the Sho~dan programme approaches completion, we are proud of our accomplishments so far and would like to share our story behind our modernisation project, with the hope it will resonate with many engineering teams out there undergoing similar transformations.

Over the coming months, we will be releasing a series of engineering blog posts providing a deeper-dive into  aspects of the Sho~dan programme and the approaches we have taken towards engineering at Judopay.

‍

Why Sho~dan?

We named this project Sho~dan (Japanese for first dan, or first rank), because we consider it the first phase of a new beginning in our tech platform.

‍

What are some key tenets for your team which have lead to your success?

James

Taking the time to do things right…

As a development team, we have put an emphasis on taking the time to do things right, helping to avoid as much technical debt later on.

We take the opportunity to explore new approaches and technology in order to achieve more optimum solutions. I have relished the opportunity to innovate and try something new, rather than sticking with the status quo.

Taking the time as a team to have these discussions upfront and bounce ideas off each other, in my mind  has led to better solutions and a great team dynamic.

‍

David

Reducing Toil…

As a system grows and matures, it is very easy to become bogged down in regular maintenance tasks just trying to keep everything running and secure.

Keeping systems up to date with:

  • Patches
  • Rotating keys
  • Certificates or Passwords
  • Data clean-ups
  • Scaling Systems to meet growing demand
  • A never ending list of other day-to-day tasks

If we didn’t automate these tasks we would be spending all our time just keeping the lights on! Our team has put a high emphasis on reducing this manual toil, making sure that as we implement new systems or tools, we immediately automate any accompanying maintenance tasks.

This means it can take a bit longer to implement a new system, but we feel that the longer a manual task is left un-automated, the more entrenched it becomes.  So wherever possible we try to automate as much as we can up front.

I think this has been crucial to the success of the team, both in being able to keep up with the evolving needs of the business, and also increasing the satisfaction of the engineers in the team since almost all mindless, repetitive tasks have been eliminated.

‍

What is your team’s biggest challenge?

David

Balancing reliability and stability versus innovation…

Our engineering team faces significant challenges:

  • Balancing our need to undertake this modernisation effort
  • Deliver new features
  • Our responsibility to maintain a stable and reliable system for our merchants

Payments is a 24/7/365 service. We do not have the luxury of maintenance windows to leverage, along with a low appetite for risk given the zero-tolerance expectation with regards to service outage.

It was a constant consideration not to impact our merchants. This meant adopting a gradual phasing in of Sho~dan, all while our legacy system was still running. Given the size of the Sho~dan programme, it was also not practical to put a change freeze on our legacy system, as continually maintaining and adding new features was essential to our business.

This meant simultaneously building an entirely new system, then seamlessly integrating it with our legacy system as it began to take over various functions.

To reduce risk, we adopted the stangler pattern. Our microservice based architecture helped a lot too.

Our CEO, Jeremy, described the process as:

“We upgraded our aircraft to a rocket ship, all whilst the aircraft is in mid-flight”

‍

Philip

New Technologies, New Products…

As a developer you are always learning. The Sho~dan programme presented some enjoyable learning challenges.

We wanted to build a payments system that was both reliable and scalable. We chose to use the Lagom framework for this task. However, this was a new technology for all of us. Learning how to make the best use of it was a key challenge. A challenge that we met.

Over the past few years, we have managed to settle on our own preferred practices and even built up our own Lagom-based software libraries to help with our development tasks. Writing a Lagom microservice is now much easier for us!

As Sho~dan was the preferred platform for new products, this meant we had to understand how new products worked, for example Pay by Bank app and PayPal. This was in addition to deepening our knowledge of the evolving payment landscape.

‍

With the power of hindsight, is there anything you would do differently?

Philip

Working harder to get everyone on the same page…

Overall, I believe this was a proud and exciting journey for the engineering team. However, this involved a considerable shift in thinking, and at times the learning curve was pretty steep.

We facilitated this with regular discussions in open forums where the team could challenge ideas, address concerns and review materials introducing the concepts we were bringing in.

Also, we gave ourselves space for trial and error. When you are learning to use a new technology it is to be expected that some of your initial coding attempts will be missteps. However, in some instances we could have been faster to pick up where improvements needed to be made.

We hope to bundle our learnings into an induction program, so that new joiners have a running start when they begin to work with our code.

‍

David

Not a lot…

Honestly, there’s not a lot I would do differently. There are certainly minor technology choices I would change. The world of IT moves so quickly. There is always a new technology, solving a problem in a slightly better way.

On the whole I am really happy with the approaches we have taken and our technology choices.

‍

Did you encounter any unexpected developments or learnings during the Sho~dan programme?

Philip

Scala has been great…

One of the unexpected outcomes going into Sho~dan has been the adoption of Scala as our backend language of choice, even though this wasn’t necessarily a change we were looking at.

However, Scala is a popular language with a wealth of libraries available, and a dedicated community able to offer advice. We relished the challenge of mastering this language.

Speaking personally, I initially found Scala’s more functional style rather fussy, but I came to appreciate it. It encourages us to write more modular code - functions that are easy to read, test and re-use. Not to mention Scala also frees us from the curse of the null pointer exception.

‍

David

All the time…

Sho~dan has transitioned us from a monolithic .NET system running on Windows servers, to a microservice based, mostly Scala system, running in Kubernetes.

We have moved from storing data using traditional, self-managed RDBMS, to unlocking greater data potential with Cassandra, Kafka, CloudSQL and BigQuery.

With such a monumental shift in technologies and approaches, we were always encountering the unexpected, but learning different tools and technologies is one of the best parts of my job. Adapting to the unexpected challenges we encounter is great fun and pushes us all to become better, more well-rounded engineers.

‍

Philip

A Change of Course…

Sho~dan has been a significant project, and one in which a lot of time has been invested. Of course, businesses don’t stand still, and the Sho~dan programme has also catered for changing priorities and new opportunities.

Around the same time we began work on the Sho~dan architecture, Judopay was given the opportunity to offer Pay-by-Bank-app as a payment option. Pay by Bank app is not card-based, and it would have been challenging to incorporate it with our existing solution - a monolith system designed around card payments.

However, given the way we designed Sho~dan’s microservice architecture, it was more straightforward to create a dedicated Pay-by-Bank-app service that would work within the network of services we were writing.

As the Sho~dan systems have been designed with flexibility in mind, adapting to these new requirements and priorities has been relatively easy.

‍

James

Functional Programming…

Scala encourages some programming techniques such as adopting use of pure functions and immutability wherever possible (which are tenets of functional programming) - this was a learning curve. Taking the effort to go ‘all-in’ with Scala at times took longer, but ended up being a reward, as I believe it has led to us writing more robust code with less bugs.

The functional approach also lends itself well to the distributed architecture we are using with event stores and eventual consistency.

‍

What are you most proud of?

David

Our Automation…

 I believe we have done a great job automating as much as we have!

  • We have a really mature continuous integration and delivery platform, with a short feedback loop for developers.
  • We have covered virtually 100% of our infrastructure, as Infrastructure-as-code.
  • We have also developed mature continuous deployment pipelines for our infrastructure changes, and have built continuous maintenance systems to keep our applications and infrastructure up to date.

Many engineering teams have some or all of this in place, but in my experience not many have executed it as well as we have.

‍

James

Reduce re-inventing the wheel…

Our adoption of microservices has required us to implement a number of services, with some similar tasks and shared structure. In many cases related building blocks of logic are used in multiple services creating potential repetition. This has led to us building a fairly comprehensive set of ‘commons’ tools and programming packages.

This has been a benefit for improving maintainability, while also building a familiar structure for each service and has helped us achieve high unit test coverage with a lower amount of effort.


What does the future look like for Judopay’s Engineering team?

David

A greater focus on data engineering…

As Sho~dan moves towards completion, we have been working on plans for Ni~dan (our second dan).

A large component of this will be focused on improving our data engineering practices. Building real-time data systems based on ideas such as Data Mesh and Event Sourcing. We are excited to see the value we can provide to our merchants, with these improved data insights.

‍


Recent posts.

Growth tips

Mobility taxi image for payments

Smooth & Seamless. Gen Z & Millennial payment preferences

Read morePurple background blob

Engineering

Judopay and Mobo2Go case study imageTeal background blob

API Bridge Continued ~ Bringing the Bridge to Life...

Read more

Growth tips

Strong Customer AuthenticationPink background blob

7 ways bars can reduce wait times and boost sales

Read more
Judo logo

Our solution

Online paymentsFraud protectionReporting tools

Company

AboutCustomersPartnersCareersBlogPress

Developers

DocumentationDeveloper hubChangelogAPI referenceStatus page

© Judopay 2023. All rights reserved.

Alternative Payments Limited (Company Number 07959933) t/a Judopay is wholly owned by Fabrick S.p.A., part of the Banca Sella Group.

Service agreementCertificatesLegal hubPrivacy policy
Terms & conditionsPrivacy notice for job applicants
Cookie Policy
PCI DSS
ISO27001 logo
Cyber Essential Plus logo
ico registered logo

© Judopay 2023. All rights reserved.