Learnings from building a new feature while moving away from monolithic

applicationBuilding Request Money after MVP success

the new feature: TransferWise Request Money

Bob sends a link to Alex for the rentAlex pays with TransferWise

currencies can be different or the same

Goal for the New Feature

Use all the functionalities we have in TransferWise,

without pushing more code into our monolith

Solution

Microservice

+

Monolith refactor

What is TransferWise’s monolithic application ?

Real Life example: TransferWise Send Money

£

€

Teams who collaborate to help user send money

Conversion Team~ Send money flow

Experience Team~ user

Verification Team~ verify user

Card Team~ payment with card

Payment Processing Team

~ process a transfer

Fraud Team~ prevent fraud

Ops Team~ pay-outs

CS Team~ help customer

Business Team~ business users

Currency Team~ bring new currency

Marketing Team~ bring new users

Virality Team~ referral

All teams work together tomake TransferWise

help customers

Good Reality

Now let’s build the new feature: TransferWise Request Money

Bob sends a link to Alex for the rentAlex pays with TransferWise

currencies can be different or the same

Some resources cannot be used as dependenciesTeams could be better masters of their productivity

Some dependencies can be too invasive

Good dependency Bad dependencyVS

Sad Reality

If we have a single interaction point between 2 “code areas”then if one “code area” evolveswe only have to modify the interaction point

Code Area in TransferWise ~

Code Weakly Owned by an Independant Team

APIs are good, especially in monoliths

Shared usage of classes/interfaces between different business domains

If we can use another business domain’s classes/interfaces, we will:it’s quite convenient since:- they already have very useful methods on them - they represent the data I need

And if we’re missing a feature or property for that business domain, what should we do ?Since we already use this class a lot, we’re just going to add a public method or a property to the class.

Maintaining a good monolith is hard

Statistically more unnecessary tight coupling of complex types

!=

What is the API provided by ?

Onboarding is hardRequired knowledge & experience can be unnecessarily high

One team’s productivity can depend too much on the other teams productivity- Time to run tests- Time to deploy

Discovery can be hard- Who to talk to → “git annotations”- Where to do what → “probably there”- What services, tools can/can’t we use → “depends, several”

Mistakes and bad practices can be- less contained- more harmful

→ “Easy to review and refactor readable code that follows SRP”→ bad code stays alive longer → gets more used → ...

Working with a big monolith can be hard

If we never share our internal business domain logic, we can make it evolve freely

If the public presentation of our business domain returns plain objects,our clients will suffer from less coupling

If we physically encapsulate our business domain logic, our delivery will only depend on our team (CI, tests, infrastructure changes, …)

How can we be more independant ?

Good real life example: REST APIs

Possible Solution: Micro Service

Where we are nowUse TransferWise’s magic without bad dependencies

Main Learnings

It’s hard to maintain a monolithic application

Always have a clear view of all the business logic

Separate different business domains asap (= communicate with plain objects)

Microservices are great to reduce tight coupling risks

eventually

Figure out infrastructure first / in parallel → have a ‘Hello world!’ deployed asap

Talk to all teams we plan to depend on → have a good understanding of dependencies

Collaborate in person first → Anticipate, meet, organize workshops

Work on the monolith as well and try to be a boy scout there → we all depend on it

Main Learnings

It pays off for everyone in the end

→ We have to think about physical boundaries

→ Which team should build most of their logic behind which boundary ?

Tricky part: How do we identify a business domain ?

Main Learnings

Discussion

How about extracting existing business logic into Microservices ?

Goal for the New Feature

Use all the functionalities we had in TransferWise,

without pushing more code into our monolithdev efforts

product evolution

monolithmicroservicemvp