This section gives a peek into the kitchen of the implementation of ILSA. You don’t need to read this, but might find it interesting.
ILSA consists of two main components: The searchapi and the core. The searchapi serves the API requests, usually directly from your visitors’ browsers. We run multiple redundant searchapi servers which are all perfectly interchangeable. Their only dependency is a datafile that contains everything about your instance needed to serve requests. This datafile contains your configuration, your vehicles, and optimized indexes for fast searching. When vehicles are added, updated or removed the datafile will be replaced and future requests will be served from the new datafile.
These datafiles are produced by the core. The core is where most of the complexity lies. It receives vehicles from DV, calculates more fields (like pricing information), calls your enrichers, indexes your vehicles and finally produces new datafiles. These datafiles are run through our CI which runs a number of tests on your datafile. Which tests is decided by your instance configuration, and by the recent live requests that were done on your instance. These datafiles are then distributed to all searchapi servers.
By using multiple redundant searchapi servers that all have low complexity dependencies we’ve minimized the chance of outages. For example if your enricher inadvertently goes offline, the core won’t be able to add new vehicles, but your website will keep working. A few months after our launch there was a network outage between the core and some of our searchapi servers. We couldn’t push new datafiles for a few hours, but all websites kept functioning perfectly.
To be as fast as we can, as little work as possible is done inside the searchapi. And less work means less code means less bugs means less outages. Even the JSON you’ll get from /vehicle and /searchresults calls is precalculated.