A story of 3 bets - Tech Values - Part 2

In an earlier post, we shared how we think about Engineering Values at Endowus and how they guide our decision making. In this post, we will share some instances where we applied these values in real scenarios.

By the way, we also covered this topic in a talk titled “From Theory to Practice: How Engineering Values Inform Technology Decisions,” at APIdays Singapore 2023. The complete talk can be viewed on YouTube.

If you haven’t perused the previous article, we recommend reading that first for better context!

To recap:

Our engineering values can be summed up as: build the right thing and ship it fast.

And:

Our values lead us to make engineering decisions that help us build the right thing for our clients, our employees, our regulators and our business at a high velocity.

Making tech bets based on our values

At Endowus, we take pride in the wealth tech platform that we’ve built entirely in-house. This includes the client facing applications on web and mobile, the backend services that support investing, dealing, settlement, distribution, reporting, and other business flows, as well as our risk & operations capabilities. This feat is made possible by our immensely skilled team with expertise and experience spanning product, tech, and operations from various companies.

As the picture shows, we leverage a wide variety of tech, including many amazing open source projects that we are immensely grateful for. Our selection of tech aligns with our values of building the right thing and shipping it fast.

In this post, we’ll discuss three instances where we used our values to make tech decisions that may have appeared quite risky as they deviated from the established path. However, when assessed through the lens of our values, they were sensible and encouraged us to proceed.

Language Bet: Scala

We’ve written nearly all our backend services in Scala, a JVM language created by Dr. Martin Odersky in 2002.

It’s a highly functional language ideal for financial programming, offering excellent performance running on the Java virtual machine, one of the most reliable and optimised language runtimes available.

The Risk

Five years ago, when we started, Scala had a decent global community base. But in Singapore, its popularity was lacking. This meant it could be challenging to hire developers.

The Bet

Despite this, we bet on Scala. The language offers significant productivity gains through its highly functional syntax. With a large amount of source code required to launch our platform, the productivity boost from Scala allowed us to reduce our code by a factor of 2-3 times. This was critical, particularly in our early days when speed was of the essence – echoing our “ship it fast” motto.

Paradoxically, while choosing Scala shrunk our candidate pool in Singapore, it enhanced our chances of attracting top backend developers drawn to the language. Some of our early joiners, who are still with us, were attracted by the possibility of using Scala full-time in their work. So, while Scala may limit the candidate pool size, it provides us a unique competitive advantage in attracting top engineering talents in this competitive market.

Framework bet: Flutter

Our second bet is on Flutter for our mobile apps. Flutter, a cross-platform app development framework from Google, enables teams to ship apps for multiple platforms from one code base, with one unified UI, without compromising on performance.

The Risk

In 2019, when we were deciding on the tech stack for our mobile apps, choosing Flutter was risky. The framework was quite young, hitting 1.0 in Dec 2019, just when we decided to go all-in on Flutter.

The Bet

The cross-platform nature of Flutter meant that we could swiftly deliver to both Android & iOS platforms with a single engineering team. The unified UI assured us that we could translate our designs into code once, ensuring an excellent client experience on both mobile platforms without a compromise on performance.

Flutter’s support for sophisticated state-preserving hot reloading was another incentive, significantly improving our productivity.

Furthermore, Flutter didn’t hamper our ability to deliver fluid animations, sophisticated charts, and other rich application behaviours that we wanted our clients to experience. We could create the right experience and yet ship it fast.

Nevertheless, when we started working with Flutter, the ecosystem in those early days wasn’t as rich as that of other frameworks. We took it in our stride, sending PRs to existing projects to improve them and even open sourcing our work, like our Auto Size TextField widget.

Architecture bet: Event Sourcing

Our third bet to share here is on Event Sourcing as an architecture pattern.

For those unfamiliar with Event Sourcing, let us try and provide a quick explanation. In most systems, we preserve the latest state of an object or entity. A Create, Update, Delete (CrUD) operation results in the in-place updating and replacement of the entity’s state with its latest version. If we consider the system as a database, this operation equates to updating an existing row in a table.

However, in an Event Sourcing system, the state of an entity is maintained as a sequential series of events, with the latest state being a projection of all preceding events. To put it in the context of a database system, this method would involve adding a new row for every event, rather than updating existing ones.

It’s important to note that events in this context are not mere by-products of CRUD operations. Instead, they hold a first-class status in the system’s architecture.

This architecture offers scalability and auditability, which are crucial for a fintech like us.

The Risk

This bet was risky because event-sourced systems are harder to comprehend and require a steep learning curve.

The Bet

We decided to invest in this pattern because it aligns well with a microservices architecture. Event-driven microservices, unlike event-sourced ones, often grapple with atomic publish and update semantics between services.

To illustrate, let’s take a Portfolio Service that must create and update orders, then dispatch messages to a Performance Service, which uses the message to recalculate portfolio-level performance. In an event driven (CRUD) system, these two steps represent separate operations. This separation could result in inconsistencies between the Portfolio and Performance Services, particularly in case of operational failures.Event Sourcing, on the other hand, combines these two into a single atomic operation because both services base their functionality on events.

Through this approach, we achieve reliable (albeit eventual) consistency across microservices via dependable event updates. An added benefit is the establishment of a 100% reliable audit trail, as our primary data store essentially becomes a complete record of all events.

We used the Lagom/Akka framework for building our microservices, which supports Event Sourcing. Our primary Event Store is in Cassandra, and we also used the CQRS pattern to facilitate querying data using PostgreSQL.

Don’t just follow the herd.

Hopefully, these three examples of tech bets give you some insight into how our decisions align with our value of building the right thing and shipping it fast.

We urge you not to blindly follow the herd. It’s safe to bet on the popular, but global popularity shouldn’t be the sole determinant of your technology choices.

Your business, your context, and your engineering values are unique. Let them guide your technology decisions.