RevoGain Software Architecture
If you are trading Stocks and Crypto using Revolut, then you are going to love RevoGain!
In this article, I’m going to show you the RevoGain software architecture.
RevoGain is a web application that helps Revolut users calculate their stocks and crypto trading gains, and I started building it at the beginning of September 2021.
Hype vs. Reality
Have you ever been to a software conference and felt disconnected from all those hyped technologies that were presented so beautifully on stage? I certainly had.
Whenever I came back from a software conference and looked at my project codebase, I could see a large gap between what’s being proposed as the next big thing and the battle-tested software technologies my projects were built with.
On social media, there are lots of people who are talking about shiny new technologies that aim to solve problems I’ve never had.
Any technology has a purpose, of course. However, as software developers, our goal is to identify what’s the best way to solve a given business problem. Sometimes, a newer technology can be the right answer. But, most of the time, a boring technology might be what you really need.
There’s no reactive programming or reactive database access. Just JDBC-based access.
There is no Kubernetes, no microservices, no hexagonal architecture, no DDD, no CQRS, no Event Sourcing, no Kafka, and not any of the popular NoSQL databases. Just a three-tier monolith that uses MySQL.
All those technologies are certainly useful. However, they are not needed to build RevoGain.
Here’s what I used to build the front-end layer:
While Angular, React, and Vue have many advantages, in my case, choosing any of those would prevent me from launching the product into production in just two months for a very simple reason. I don’t know how to effectively use any of those technologies. So, it would take me quite a lot of time to become proficient enough to implement any possible front-end task with ease.
And, there’s no free lunch. The moment you adopt a SPA (Single Page Application) design, you have to know what you are trading off. For example, there are some lesser-known drawbacks to using Single Page Applications that make it harder to do SEO properly.
The boring theme continues with the back-end layer:
The first time I used Spring was November 2004. 17 years later, and I’m still using Spring.
The web layer uses Spring MVC and Spring Rest. The HTML pages are built dynamically using Thymeleaf templates.
The data access layer uses Spring Data JPA and Hibernate. Eating your own dog food is the only way. For 17 years, Hibernate has worked like a charm for me. Having seen people struggling with it was my motivation to write the High-Performance Java Persistence book.
When used properly, JPA and Hibernate are a wonderful combination that allows you to develop the data access layer extremely fast without compromising performance.
And, because I have other people working on the project, I set up Hypersistence Optimizer to analyze the JPA and Hibernate usage and trigger a build failure if a code change could affect application performance.
No surprise here as well:
I’m using Amazon Aurora for MySQL because it’s very easy to set up, handles backups automatically, and provides monitoring as well.
Now, Amazon Aurora offers both MySQL and PostgreSQL, and many of my readers believe that PostgreSQL is always a better choice. But, that’s not true. Both MySQL and PostgreSQL have pros and cons.
The decision of using MySQL was taken because of the following aspects:
- most of the data access is done via the Clustered Index
- MySQL can use a very large Buffer Bool and because it uses Direct I/O, there’s no double buffering
- the undo log is more compact in MySQL
- the Serializable mode is based on locking, and the probability of MVCC-based rollbacks is lower
- MySQL uses range locks, which are missing in PostgreSQL
So, while, in general, both MySQL and PostgreSQL are great database products, for this particular web application, MySQL is a much better fit.
Architecture is by purpose. The goal of a software project is to turn a business idea into a working solution. The tech choice should resonate with the business goals. Otherwise, the project will suffer.
In my case, I was very interested in Time To Market. I don’t want to spend a long time building something the users won’t need. So, instead, I prefer launching rapidly and evolving the product based on real-life user feedback. The user knows best. The application is for the user, not for me. The user shapes how the project should be used.
Using a boring stack that I know very well allows me to focus on features rather than tech issues. In the first two weeks since I launched it, I managed to add lots of new features based on the feedback I got from the clients.
So, if you’re software architecture doesn’t resemble at all what the latest Technology Radars or software conference trends advertise, rest assured. In the end, what really matters is to have a working solution that can adapt to user needs.