Even if this was true, you are actually starting over with a lot more knowledge of your problem domain which will usually have a positive impact in your new design. We like to emphasize that what we had at our beginning wasn't bad or wrong - we've seen developers in conferences state that everything was crap and they brilliantly had to start pretty much from scratch. A multilith - we are not sure if we made this term up or heard it somewhere else - would be like when you start breaking your huge stone into smaller stones, however usually the biggest one at the beginning still is the biggest one at the end. We now internally call this "from the monolith to the multilith". One of the main challenges that the team faced was to start breaking apart this monolith, which wasn't at all easy. However, these previous projects, aside of setting the precedent of using other programming languages and starting distributing some parts, were only scratching the surface. Change of architecture, going distributed This way we deprecated our previous custom-made Ruby task system, which wasn't up to the number of tasks and granularity needs of the new upcoming workload. We later realized that satellites are usually the first sign of needing to move towards a service oriented architecture (SOA).Īfter Odin, we developed Heracles, a background task execution system that relied on a RabbitMQ cluster and was using Python Celery at that time. It wasn't really using the API to an important extent. In the beginning of 2013, we had to create a business intelligence solution that fit our needs and thus we created Odin, which was more like a Satellite to this monolith. Having a separate API was already a big head start. We basically had an API and a frontend web application, which is better than having all in one single web application. Basic constraints were size of the team and money, and some of the advantages were reduced time to market for new features, deployments were easy, the infrastructure necessary to run all this was small and cheap and most members of the team at the time had a full picture of the platform. Three years ago ticketea was basically a monolith, an all-in-one solution that was designed this way due to some constraints and advantages at that time. Enable scalable and secure user access to web and mobile applications. This has allowed us to reach high availability which makes organizers rely on us for selling large events. Other parts have been refactored to improve robustness and quality. However, over the years and its constant growth some parts had to be redone to cope with the increasing needs of a growing demand. Ticketea is now in its sixth year of life and, like many startups, started with a simpler, more modest platform. It is nobody's responsibility to deploy or provision machines, to work in the orchestration system or to improve internal development tools, because it's everyone's responsibility. We don't have any sysadmins and this is mainly due to two things, we rely on some AWS services for hosting our projects and we all do our own devops. Developers are usually full-stack or quite multifaceted, although there are some specialists in the team. Out of those 16 members, there are 3 designers, one QA and the rest are developers. Ticketea’s product team currently counts with 16 members in charge of its development and maintenance. ![]() ![]() When a hot event goes on sale fans are willing to crush your servers. For understanding some of the architectural reasons behind ticketea, it's important to note that the ticketing business has sudden spikes in traffic. ![]() We like to think of ourselves as technological partners of event organizers, helping them and their attendees through the whole lifecycle of an event. Ticketea is an online ticketing platform present in Spain, Germany and the UK, among others.
0 Comments
Leave a Reply. |