Business reliability as a cornerstone of our architectural choices

If any of you reading this has ever bought or sold a house, I am sure complexity is one of the words you would use to describe your experience. Well, imagine if you need to buy and sell thousands of houses every year, with top-notch execution as you run an entire business on it.

We at Casavo believe that technology can handle such complexity and enable us to provide value for our customers. To achieve this, our goal is to build an infrastructure to scale our business, being able to efficiently manage more and more transactions while controlling our costs. This requires building a set of different products to really disrupt the real estate market to create a unique competitive advantage for Casavo.

Such a journey did not start recently but technology was key already at the early stages of our company. As our organization grew, we set up a dedicated team, our Scalability Tribe, to provide our team with the right tools to perform the daily activities.

In doing so, recently our team has fundamentally changed some of the key elements of our architecture to lay out the foundations for the scalability of our transactional workflow.

We started from the roots and revolutionized our approach.

We started designing our Workflow Management System to evolve and address some of the challenges we were facing:

• Our interface was essentially an evolution of a database: this implementation allowed quick setup but had all of us focusing on “add a button here, add a gate there” — solutions instead of on the problems.
• The CRUD design made our system relatively simple but not very efficient: it meant that we had a single point where we Create data, Read data, Update data or Delete data. This meant the effort required to perform a simple query made very little sense for the result provided. Moreover, any action we carried out either wrote new data (add a new lead) or read from the data (export new leads). Using the same data source for both things made our system slow and unable to manage high volumes.
• To support our company’s growth, our system had many integrations and tests were added “along the way”: this made our system vulnerable to bugs.

To evolve our system we made some choices that enable us to incrementally and continuously deliver new values and features. What are they?

The right interface guides you, it does not block you

We opted for a task-driven approach that enables the user to focus on what they have to do. We observed and talked to our Investment team to understand what they do and how they do it while considering what our company needs to carry out a transaction. We designed a solution that aims to bring speed, clarity, and guidance to daily activities.

We built a business reliable infrastructure that allows service quality monitoring

We have created multiple automation that performs continuous tests on our code: they simulate 82% of potential user behaviors, allowing us to catch bugs earlier in the process and be more confident in our releases. On top of this, we have built a system of real-time notifications to catch errors before they can affect tasks.

We are running a marathon and snapshots cannot describe our business: videos are available from today

We know that the core of what we do is based on data. And we also know that some of the transaction-related data may change over time. Let’s think about a purchase offer: what is the first offer we make? And what is the final one? And how long does it take to change the offer? How frequently? Over-writing data does not allow us to answer these questions. Because it only provides snapshots of our business. We have implemented the event-source pattern, which enables us to monitor any changes we make, any updates, anything we do.

This new approach allows us to reconstruct our processes over time, it allows us to audit them at each step, understanding who made what decision and why. And it enables us to build reporting on the different dimensions of time.

We write data here but we read data from another place: it is scalable, open and evolutive

We have separated the system where we write new data from the one where we read it. And we made the data much easier to read, leveraging ad-hoc read models. We started from the idea that the same data has to be used by different systems: our interface may want to know the property details of a potential seller, the Mobile App Visits may want to know when the property visit was scheduled, our data warehouse wants to know the offer’s value to populate our analysis. Each of these systems has a specific, ad-hoc key to read our data.

This approach is scalable, as many systems can use data at the same time. It is open, as new systems may be easily integrated and read from the data. And it is evolutive, as new typologies of data input do not impede our ability to keep running.

We changed the rules of the game to scale our business

The choices we made not only radically changed our approach but resulted in delivering massive advantages from two perspectives:

• On one side, from a business perspective, we are now faster in delivering, reducing our time to market. We are also able to modularly integrate new pieces into our software architecture. And we are evolutive, being able to change the way we do things one step at a time, with no impact on the rest of the system.
• On the other side, from a reliability perspective, we now test everything we do. We can also scale up our volumes and continuously monitor our performances.

And this is just the tip of the iceberg! It’s the first step of an exciting journey enabling us to completely transform the way we handle real estate transactions. If you want to join us, we are waiting for you: check out our openings and join our team!