Our technology team has grown, too – now numbering over 50 people, and we’re still hiring.
As such, I wanted to write about what the back-end engineering team is doing to build a back-end function that is primed to meet the demands of a growing and innovative bank.
It’s a sprint, not a marathon
Firstly, it’s worth taking a moment to talk about how we work. We operate in ‘squads’, made up of lots of different functions – front-end engineers, product owners, testers, designers, data engineers and all sorts – all focused on one common goal or project. For example, I am part of the Asset Finance squad, looking after our Asset Finance products.
Squads work in two-week sprints, meaning we’re constantly releasing, and can easily showcase what we’ve achieved to the rest of the bank. This is all part of Allica’s ‘scrum environment’, designed to keep our work transparent and agile.
A typical sprint for a back-end engineer could involve working on an API, for example, which enable our systems to integrate with third parties. We also build our own internal APIs so that we can communicate across systems. As you can probably tell, Allica has a comprehensive and fluid API ecosystem that all our back-end engineers work with on a day-to-day basis, regardless of the squad we are part of.
Architecture built to scale
Allica is currently in an exciting stage of growth as we launch new products and welcome on board thousands of new customers. This has a huge bearing on all the architecture and design decisions that we make as a back-end engineering team. We may work in two-week sprints, but we are always thinking about our vision for one, two and five years down the line.
This is why we have chosen to deploy a microservices architecture – an approach that uses lots of smaller, independent services that talk to each other and form part of a larger application architecture. By using the REST architectural style and event-driven microservices, it is immensely scalable, allowing us to integrate across internal and external systems.
Our tech stack
Hosted on Azure Spring Cloud, we maintain a uniform tech stack across our squads to allow us to scale activity up and down ‘on demand’ and, if necessary, share resources.
We consolidate all our logs into Elastic, which allows us to search and monitor the logs across all our systems. We store our source code and pipelines within Azure DevOps, giving us a single place for all our development workflows.
Some of the other tech that a back-end engineer may typically encounter at Allica are:
- Spring Boot –the framework we use to build our microservices.
- Kotlin –the language we use for building our microservices.
- WebFlux and R2DBC – for asynchronous communication to other services and databases.
- MuleSoft and AnyPoint Platform – which host our older APIs.
I have always really enjoyed working within Allica’s tech stack. It’s robust and provides great opportunities to learn about different systems and applications.
Thinking beyond the back-end
A major benefit of the way we work at Allica is what we learn outside of our core role. For example, how a growing fintech bank works. To build a secure and innovative bank, we need to identify challenges and opportunities early. This means always being aware of the environmental factors that could affect the bank and being close to the customer and the market in general.
For example, the interest rates offered by Allica’s business and personal savings accounts fluctuate based upon market demand. When we’re offering some of the highest rates on the market, this will be reported in MoneySavingExpert’s best buy tables, often resulting in a huge spike in demand. When this happens, we need to keep a very close eye on the performance of our APIs!
As Allica continues to scale in 2022, it’s vital that we maintain a culture that supports well-rounded, collaborative and multi-skilled technologists. After all, our technology will only be as forward-thinking, adaptable and robust as the team that builds it.