Development of a Ticketing Platform for Formula 1

Here at Impressit, we are really proud of the level of expertise and experience our developers have. In a highly competitive environment of IT service companies, we choose to constantly boost our skills to be know-how professionals, not just theoreticians. 

My personal journey as a developer started more than 10 years ago. Now, as a CTO of a growing company, with plenty of interesting projects behind my back, it is time to share my experiences to once again prove the level of professionalism we nurture at Impressit and showcase that our team is ready to tackle the challenges in any domain.

In this particular article, I would like to share a story of the development of the official ticketing platform for none other than the queen of motorsports — Formula 1. Currently (as of January 2024), the monthly organic traffic of the platform is around 104 thousand visitors. Meanwhile, the 2023 season of the race broke all records with 6 million Formula 1 weekend attendances across the 22 races. And it is safe to say that although there are a few platforms that resell F1 tickets, a significant portion of the tickets are sold through the official Formula 1 ticketing platform that I had a chance to work on.

I took on the team lead role of this ambitious project, which was not only a tremendous technological experience but also a challenging managerial task that propelled my growth as a technology leader.

Common Challenges of Ticket Shop\Online Booking Platform Development 

Let’s preface this by discussing a few general things about the development of ticketing solutions and online booking platforms. What might seem like just another project, actually isn't that simple and has certain challenges and limitations that are absolutely necessary to take into account.

So what are those challenges? 

• Multiple booking options. The more ticket options one’s platform offers, the more challenging the development process might be. Especially if the platform offers tickets for events at different venues in different countries with each particular case posing certain rules and limitations inside the system.   
• Security compliance. Protecting the user data is obviously of utmost importance. Secure payment gateways, encryption, and regular security audits are just some of the measures that are essential to ensure that your client’s personal information is not under any threat.
• Laws and regulations. Besides the good old General Data Protection Regulation (GDPR), there are numerous regulations and laws that one’s ticketing shop should follow. These regulations might be industry or country-specific. Nevertheless, the product should be developed with these in mind.
• Integration with existing software. Another important detail to keep in mind is whether the business already uses certain kinds of software and if the ticket shop or booking app should integrate with these. If the answer is positive, one of the tasks of the development team would be to ensure seamless integration.
• Costs. Last but not least, I should mention the costs. Whether one looks to develop a ticketing shop from scratch or already has some kind of solution running, creating a complex product such as a ticketing system will require significant investment.

Of course, not every development team will face each and every one of these challenges in the process of creating a booking platform or a ticket shop. However, it is still important to be aware of these and assess all the possible risks and obstacles at the early stages of development.  

Development of a Solution Used by F1® Ticket Store

Long before I became a part of this project, the development of the platform began using the PHP and PrestaShop e-commerce platform with MySQL database. This ticket shop platform served as a backend. Interfaces of the websites of individual events (among which was Formula 1, the Madrid Open tennis tournament, and others) are connected to this backend.

 Because of this, the backend had to be developed in such a way that would allow having multiple booking options e.g. the developers had to customize it for each particular case. This way, at a certain point, it became impossible to scale the project further. Moreover, the engineers had to search for, discover, and fix bugs that appeared as a result of the rapid development and growth of the platform.

So, at this point, the client found themselves in need of expert assistance and started looking for a strategic technology partner who could help them design and build a new scalable architecture. I joined the development team as a team lead when four developers have already started working on it. At the peak development period, I was managing up to 25 people.

Our dedicated team of skilled developers was able to quickly assess the existing platform, identify key areas for improvement, and devise a comprehensive modernization plan. Our expertise in selecting the right technologies and designing a scalable architecture ensured that the new system would meet the client's current needs and allow for future growth. Throughout the development process, our team worked closely with the client, providing regular updates and incorporating feedback to ensure that the final product would exceed expectations. Our team indeed played an important role in development as we were delivering the results on time and within budget, setting this ticketing platform for long-term success.

Let’s look at the development process in more detail.

Reviewing the legacy code

By reviewing the legacy code, developers can identify areas for improvement, such as refactoring to improve code quality, performance optimizations, or updating dependencies to ensure security and compatibility with modern standards. Additionally, reviewing legacy code allows developers to gain a deeper understanding of the system's architecture and functionality, which is essential for planning and implementing any changes or enhancements. 

As I've mentioned earlier, the platform was initially created with PHP and PrestaShop CMS. At that moment, the choice of this tech stack was logical. PrestaShop is a quite comprehensive system for e-commerce, and it still exists and is used today. 

However, by the time I joined the project, so many lines of custom code were added that frankly speaking, it had almost nothing to do with PrestaShop except the titles of the tables in the database. Therefore, what I had to deal with when I joined the development team was a lot of legacy code, often poorly written.

During the first few weeks of my involvement with the project as a team lead I had time to dig deeper, evaluate the current situation, and plan the next steps. After hours of reading the code line by line, it became obvious to me that I would have to create a new architecture for this whole system. Hence, the next few months I spent researching and choosing the proper tech stack,  crafting the development strategy, and creating POCs and presentations to showcase my plans and ideas to the client.

After my plan was approved and greenlighted, I was ready to start. Obviously, since we had thousands of lines of legacy code to deal with, our team (4 or 5 developers at that moment. However, later more than 25 people will work on it) started with the refactoring. 

Switching to Symfony

As I’ve mentioned before, by the time I joined the project, everything that was developed initially using PrestaShop was rewritten so many times I actually did not have any experience with the PrestaShop as it is on this project. Thus, there was a need to choose the tech stack that would allow the successful development, scaling, and maintenance of this complicated system.

Choosing the proper tech stack is crucial for the success of any software project. A well-chosen tech stack can greatly impact the performance, scalability, and maintainability of the software. It can also affect the speed of development and the ability to adapt to future changes and advancements in technology. By carefully selecting the right tech stack for a project, developers can ensure that they are using the most suitable tools for the job, leading to a more efficient development process and a higher quality end product.

At that moment, for me the choice was obvious — Symfony. It was then and even today is one of the most powerful tools for developing large, powerful applications. Both our team and the team on the client’s side had experience with this framework, which was another factor that contributed to this decision. We also used PHPUnit in conjunction with Symfony.

It should be noted that we did not use the entire Symfony in its entirety. This framework consists of many components and allows you to flexibly use only those components that you need. 

Our task was not to completely rewrite everything from scratch but to support the existing system at that time and to transfer it in parallel to a new solution. This way, first of all, we took about 6-7 main Symfony components that we needed and began to integrate them. These were components that worked with routing, parsing of requests, request body, etc.

In short, it was more of a no-compromise choice to make. There were other options, for instance, to use Laravel, which is also a pretty good framework, but it is built with Symfony components anyway. Basically, everyone involved understood that Symfony is a more powerful tool for this kind of solution.

Developing backend and frontend

To give you a better understanding of the system, it worked as follows: there are many different frontends for various events in different venues and countries. These frontends are attached to the backend, which consists of a few parts. That’s why the old frontends could not be transferred to a new backend so easily. 

For this, it was necessary to create a development plan that would allow migration to modern approaches, architecture and technologies, to recycle the existing legacy code. Most importantly, do it without breaking the existing frontends and the existing communication with the server. That is why migration was done step by step.

This way, we started to transfer the existing system. And then just piece by piece we began to switch from what was done before to our new solution. We did not change the structure of the database because, obviously, it would lead to a breakdown.

It was necessary to do a lot of wrappers on current solutions, which simply wrapped pieces of legacy code in there, which we also could not completely change. It was quite complicated for the team that refactored it. Also considering that work on the backend and frontend went in parallel.

Speaking of the frontend development, a separate team of engineers was responsible for it. The initial quality of the code was, to put it mildly, unsatisfactory. Moreover, it was tied to the backend, and did not work as an API but directly as a server-side rendering application. 

The situation was bad; this solution for frontend did not work properly. Mainly because for each ticket shop it was necessary to hardcode many different things for each client, which was very inconvenient from the point of view of development and code quality.

The only logical decision was to completely rewrite the frontend. We opted for using Angular with an admin part as just a separate service on Symfony. When we finished, it worked as a full-fledged API type with a separate isolated frontend.

All in all, the project involved a complex process of migrating the existing system to modern approaches and technologies while recycling legacy code. The challenge was to achieve this without disrupting the existing frontends and server communication, necessitating a careful, step-by-step migration plan. 

Despite the complexity, the team successfully transferred the system piece by piece, gradually transitioning to the new solution without altering the database structure. Wrapping legacy code in wrappers proved to be a significant challenge, as it required encapsulating existing code without a complete overhaul. The decision to rewrite the frontend was pivotal, leading to the adoption of Angular and a separate admin service on Symfony, resulting in a more efficient and isolated frontend operating as a full-fledged API. Overall, the project showcased the team's ability to overcome intricate challenges and deliver a successful migration to modern technologies.

Challenges

Last but not least, in this last part of the article, I will tell you about probably the most interesting thing — the most challenging part of this project. Overcoming challenges in software development is an inherent part of the process, requiring adaptability, creativity, and perseverance. In this particular case, the part that called for the most creativity was working with card readers and the inclusion of multiple booking option possibilities.

Multiple booking options

To give you the context, selling the tickets to Formula 1 Grand Prix in Monaco and to Formula 1 Grand Prix in Saudi Arabia are two different processes. The same is true with selling tickets to different types of events even in the same country (e.g. Formula 1 British Grand Prix and Wimbledon) — they do have different selling rules and limitations.

Therefore, we had to come up with the architecture of the application that would make the configuration of the sales rules for each event and venue possible and relatively easy. Please note that these configurations were not handled by us but by the back office of the client. So these configurations had to be made easily and quickly for each new client that might have a specific type of event at a specific venue with a whole new set of selling rules.

Working with hardware

As I’ve said, this domain is not as simple as it might seem at first glance. One of the challenges we faced concerned working with the card readers. 

When the company sells tickets for an event, these tickets have to be signed digitally. The digital signature is contained in the algorithm that was on the SD card that was installed in some particular data center. This has a lot to do with security, so the client company had to actually get permission for us to have access to this hardware and work with these digital signatures.

After all, we were sent a card reader and SD cards to our office. We were able to connect to the data center to try and test these cards. Part of our team wrote software using Java that connected to actual hardware and ran an algorithm through it, allowing the tickets to be digitally signed. As the last part of this task, we had to combine this part with our main platform.

This experience showed me that the development of the ticketing platforms has a lot of pitfalls. Thinking of it as just another website\app development is very wrong considering all the tricky details and possible challenges in the development process.

Another challenge worth mentioning is the necessity to create the possibility for the platform to work on-site via virtual servers with no internet connection. Meaning that the platform still had to work in physical ticket offices and venues allowing to issue and print tickets even if the power was out or the internet connection was lost. Although this portion of the project was handled by the team on the client’s side, I still feel it’s important to acknowledge this in the article as this part of development might require significant time and resources.

In Conclusion

Developing a ticketing platform entails navigating through a myriad of challenges and complexities. From managing multiple booking options to ensuring robust security measures and complying with various regulations, the journey involves strategic planning and meticulous execution. 

Acknowledging the common challenges such as handling multiple booking options, addressing security concerns, complying with laws and regulations, integrating with existing software, and managing costs is crucial. Adopting an iterative approach to development, particularly when dealing with legacy systems, ensures smooth migration and minimal disruption to existing functionalities. Breaking down the migration process into manageable steps while maintaining backward compatibility helps mitigate risks associated with large-scale refactoring. Embracing creativity and innovation in addressing unique challenges, such as working with card readers and enabling offline functionality, underscores the importance of adaptability and problem-solving skills in the development process.

Working on this project gifted me with an invaluable experience and played a significant role in my career. Now, as a CTO, I understand how important the management experience I’ve got while working on this big project is. Although I still enjoy creating concepts and ideas as well as coding more, this project showed me how to create a solid team, lead people, and improve my soft skills.

In conclusion, developing a ticketing platform requires a holistic approach that encompasses technical expertise, strategic planning, and creative problem-solving. By understanding and addressing the challenges outlined in this article, developers can navigate the complexities of ticketing platform development more effectively, ultimately delivering robust, secure, and user-friendly solutions tailored to the needs of clients and end-users.