About Sumup

"SumUp is a global financial technology company and the leading mobile point-of-sale (mPOS) company in Europe. Thanks to SumUp, small merchants around the world are able to accept card payments anywhere their business takes them.
SumUp technology makes accepting payments simple so merchants can focus on what they do best, whether they’re brewing coffee or fixing cars. While traditional POS offerings are costly and bureaucratically complex for small businesses to attain, SumUp products are designed to be intuitive and easy-to-use, from paperless on boarding to seamless transactions.
Since its launch, SumUp has earned an impressive global reach and expanded into 31 countries, including Germany, the U.S., and Brazil. SumUp continues to grow and is backed by TPG, Bain Capital Credit, Groupon, Holtzbrinck Ventures, and other renowned venture capital investors.
Beyond the original hardware, mobile, and web apps, SumUp has also developed a suite of APIs and SDKs for integrating SumUp payment into other apps and services. Thanks to these offerings, over two million small businesses around the world rely on SumUp to simply get paid." (source: https://sumup.com/about)

Intro

In April 2017 I was sent temporarily to SumUp's Berlin office to exchange knowledge and culture with the Berlin's team. I joined the FE team in order to get more depth in their workflow and bridge the cultural gap between Backend and Frontend. A few months later I was offered the opportunity to stay permanently and establish a Backend team in the Berlin's office.

I've got the chances to be part of the interview processes for several roles, to setup a backend team, to promote free-spoken, open-minded and bold culture. In the process I faced many challenges, got many enemies and won few friends. I didn't succeed in my endeavors since my head was cut, but the learning, the outcomes, and the experience worth every single struggle.

I'd say that this time period of my career was the most emotional and most eye-opening.

Tech Stack

Ruby, Ruby on Rails, JavaScript, Node.js, HTML, CSS, RabbitMQ, PostgreSQL, Jenkins, AWS, Centos7, VIM, Git

System architecture

All backend services were accessed by the client facing ones (frontend, mobile, SDKs, APIs) through a gateway application. There was one database to rule them out, and a database for data warehousing and integration with SalesForce (populated by logical replication).

Frontend

The frontend application was rewritten to React. It had a complementary service, called web-backed, which was dedicated to serve the JS bundles and do backend calls.

Backend

The backend was a mixture of SOA, monolith and microservices. The majority was written in Ruby, the monolith was Rails app. The backend evolved in the spirit of MVPs, released ASAP in order to be first on the market. Communication between services was done by HTTP calls. Sometimes a single HTTP call spans requests across several other services and a database or external service.

Team(s)

As a lead I spent most of my time with the "Acquisition" team, consisting of 3 backend and 1 frontend engineers, 1 QA, 1 designer and a product owner. I also took part into the "Logistics" team as well as in the team of the platform leads.

Being part of the acquisition team, I was responsible for maintaining and leading the development of the services, which were named as the gateway to the SumUp's platform.

I was part of the initial Logistics team, as a kick starter and domain expert, whereas my duties were to help people understand how stuff work before logistics and what should happen next.

In the team of the platform leads I took part in discussions and decisions affecting the rest of the backend engineers across the world.

Release Process

The company walked its way to more modern devops practices, allowing people to release their pieces almost independently, using Jenkins as CI/CD. Still, a team required someone from SysOps to setup a pipeline, infrastructure, and configuration for a given service.

Before going into production, an email, including change log with jira tickets and SysOps on duty was required to be sent first.

Projects Highlights

  • Acquisition shop - the SumUp's E-commerce solution

Acquisition shop

When too many teams and people start working on the "users" service, one of the oldest, fattest services in SumUp, it became a good candidate for refactoring and splitting in smaller chunks. One of my teams was built around the e-commerce domain and we needed this "chunk" from "users", where the e-commerce happened.

The "acquisition shop", ripped out from "users", was the service, dedicated to manage the experience of purchasing SumUp's product(s), similar to the classical e-commerce:

  • List available products
  • Add a product to a shopping cart
  • Manage products from the shopping cart
  • Apply vouchers for discount

It turned out, that this service is the gateway to the whole SumUp's service offering back then. Without a reader, you cannot get access to SumUp. To get a reader, you need to buy one. And here we were with the acquisition shop. Being at such role for a service, it was not an easy job to do. Many other departments, services and humans were dependent on the successful handling of a reader purchase - logistics, data warehouse, marketing, finance, customer support, business intelligence, ... The list goes on and on.

Being so important and critical as a service, everyone was willing to stuck its exploits inside to get benefit for her department. This led to various disruptions. My team introduced code ownership and contribution guidelines, so people had to respect the rules and stop introducing breaking changes.

The "acquisition shop" being that important, was also one of the best candidates for listing out the connections between services, teams, and locations and to raise awareness. I wanted to prevent "butterfly effects" here and there, therefore, I started a map, in a form of sequence diagrams to list out all the actions when a user buys a reader. In the end we have a total of more than 20 services, 5-6 teams, 5 departments involved.

The service was also a candidate for replacement by a true e-commerce solution, like the one offered by SalesForce. Unfortunately, the company management was not aware that the "acquisition shop" was spread around the company as a cancer, and it was impossible to just take out.

At the time of writing, the "acquisition shop" is still there. Still up and running. And it is not going anywhere anytime soon.