On tech, making decisions and the illusion of knowledge
The carwow system is split across a bunch of different apps/services. We’ve also just recently released carwow.de in Germany and in doing so we made some choices on how we’d approach it.
We’re still trying to figure out if they were the right choices, and I guess only time will tell if we caused ourselves unnecessary headaches, or saved ourselves from them. In this post I’ll be arguing that our decisions were the right ones to make, in doing so perhaps I’ll learn something new too!
We’re going to be arguing against ourselves too, we’ve planned a subsequent post where we will argue for the exact opposite of this.
Unknown unknowns
We thought long and hard about how best to design our backend for Germany, but at that point in time there were just too many unknowns. From a technical standpoint, we treated it very much like an experiment and we just didn’t have enough information to be able to make any large scale architectural decisions. If history, and our own personal experiences, have taught us one thing, it’s this: whatever we choose to do now, will almost certainly be the wrong decision.
I really believe more people should try and adopt this mindset when undertaking larger projects. Why would we force ourselves to make the biggest decisions at the exact moment when we have the least information?
We simply didn’t know how successful carwow Germany was going to be; I mean we had hopes and targets and plans but ultimately it was a question of when do we invest the time? Should we spend large amounts of time up-front building a robust and scalable solution, or should we go for a leaner and rougher first draft and then polish it over time?
And how about our existing services? Should we internationalise them and try to have a shared, common codebase, or should we split and have more independence? The best we could do, and the best anyone can do at that point in time, is guess.
Previous state (pre Germany)
Here’s a very simplified version of our backend:
We have a bunch of various codebases, the details of which are unimportant here, but I’ve highlighted 3 of them.
Research site is the main website, it’s what you hit when you navigate to www.carwow.co.uk, and is named such as this is where you can explore and collect research on potential cars before you buy. it’s where all our information on cars is stored, as well as all our article content - blog posts, car reviews etc.
Quotes site is a separate codebase that deals with user specific information. once you’re done with the research and are ready to buy a car, Quotes is where we store your details, your configurations, your offers etc., as well as details of the car dealers and all their various settings. The transition across the two should be seamless, but the eagle eyed among you would have noticed the url change when you enter our car configuration process and start customising your car.
Admin site is a standalone application used internally by our account managers to oversee the system and manage user and dealer journeys through carwow. It talks to both Research and Quotes site.
Keeping it simple
We wanted to get Germany up and running with minimal effort, but without being totally mindless. We ended up with a mix of some services being internationalised, and others being completely cloned and customised:
We wanted the process for the account managers to stay exactly the same across both UK and DE, and so we kept to one single codebase, deployed to each region, with limited internationalisation (as it’s used internally, we stuck to english for both)
Quotes and Research were a different matter, the front end experience was potentially going to veer over time as we customise the experience for a German audience. Rather than try to deal with the headache of internationalising them and supporting both UK and DE quirks, we decided it would be simpler to just clone and create a separate codebase for these (also not shown in the diagram is the fact that the Research site integrates with some UK specific third-parties for some of its car data and the German equivalent doesn’t conform to the same standards so would require an alternate solution).
These diagrams are very clearly not ideal and we don’t expect them to be the final version of our architecture, but this took the least work to achieve, and we didn’t have the information at that time to know which alternative was better; we were buying ourselves some time so we could make the proper choice once we had sufficient information.
We don’t work in a vacuum (aka it’s never that simple)
At the same time as this was going on, it was becoming clearer and clearer that Quotes site was swelling to an uncomfortable size. A division was forming and we were able to see a split, leading to the birth of Dealers site; a standalone site for the dealer backend.
Which is another philosophy we try to follow here — never start with ‘microservices’. Start with a service, and break it only when it becomes too big and you can identify a clear boundary.
Similar to Admin, we wanted to keep the process for car dealers consistent across both UK and DE, and so we decided to keep one codebase, this time with more thorough internationalisation.
Taking out a loan
Sadly, splitting Quotes into two services was no simple task. There were many database tables that were used by both the dealers and users side, and untangling through the dependencies was going to be a long, laborious process; it was also one that we needed to balance with continuing to deliver features.
We decided (perhaps foolishly?) to share a database across the two applications. We split the codebase as best we could, created a separate application for dealers with it’s own database and migrated across as many tables as we could. Some were quite simple and clearly belonged in one place or the other (the tables where we store user or car dealer information, for example); we were able to move these without much difficulty and throw in some API calls across the two services where necessary.
Paying our debts
We’ve definitely acquired some tech debt through this approach, this is something we were fully aware of going in. We saved ourselves some time up front, but we need to pay that time back and be disciplined in doing so.
The pain of staying in this kind of situation for too long has become very apparent (I’ll be writing a follow up post with one specific issue we faced around testing code against multiple DB schemas - Dealers site uses the Quotes database, which was then made more complicated by the fact that the Quotes DE schema differed from the Quotes UK schema) and so we’ve decided to be more aggressive in completing the split sooner.
The hope is that we know more now than we did before, and can make smarter decisions about which direction to go in. Whether or not this hope is proven to be true is yet to be seen ;)
Interested in making an Impact? Join the carwow-team!
Feeling social? Connect with us on Twitter and LinkedIn :-)
