Client: Noveo is an international company specialized in custom software development as well as independent testing.
Project: Cizoo, online karaoke (France)
Objectives: migration to microservice architecture, protection against DDoS attacks, database migration to cloud storage
Team reinforcement: one Senior Java developer
Technology stack: Java
Period of our participation in the project: from October 2020 to June 2021
Website: noveogroup.com

Project history

Cizoo is a French online karaoke company. In fact, it is a specialized social network with access through a mobile app. In it, you record a video, like in tik-tok, and the app allows you to immediately apply a filter, tweak the voice, and adjust it to match the style of your favorite singer. You can share these videos, you can see what your friends are publishing. It’s a perfect invention for those who want to feel like a star or record a beautiful greeting to a friend.

In addition to the mobile application, Cizoo launched "live booths" (la cabine Karaoké), which are located in entertainment centers. Specialized equipment in these booths makes it possible to achieve a professional level of recording with correct acoustics. The booths have already won the love of the French and are actively used at corporate parties. Singing with colleagues without fear is a dream.

The product is present on the French domestic market, but is gradually gaining global popularity and investors are hypothetically considering entering foreign markets.  Customers use French infrastructure solutions and have recently switched from a connected hard drive to cloud storage.

Team and challenges

The French customers are business-oriented; they develop the concept of the product and ways to promote it. But to implement their rather complicated ideas, they decided to involve high-level developers. And the question of where to look for such high-level specialists led to ITQsoftware. The owners of Cizoo turned to Noveo for support. And from our side, the Noveo team was strengthened by a Senior Java developer, Valentin.

His tasks included optimizing the backend, putting it in order. For instance, the database transactions were being processed for a very long time, which caused constant errors, and there were a lot of crashes on the server. The transaction model was improved, and it reached a decent level. For business reasons, the customer is not yet ready to allocate a budget for writing optimal code. So, sooner or later, errors will accumulate again and they will have to be corrected.

Result of work

During the last period, from March to June, we implemented protection against spammers and DoS and DDoS attacks: when a large number of requests are sent simultaneously from one or many computers located on the Internet, the system can no longer handle the load and denies access to authorized users. Every cloud provider grants such protection against third-party DDoS attacks. But a similar problem can arise among authorized users of the network, when some mommy hacker inside the system can build up spam, pornography, and arrange its mass distribution in personal messages to other users. This has not been limited. We have implemented necessary protection. It’s not on the production server yet, but will appear there later. The main thing is that it already exists!

And the second important point: we have prepared the transition to cloud storage and developed microservice architecture. Right now all information is stored on the hard drive. This is, figuratively speaking, just a monster server, which is the weak point. If it goes down, that's it, Cizoo goes down. So the decision was made to abandon this solution and to move as far as possible to the interaction of small, loosely coupled and easily changeable modules - microservices. This is what we call a “microservice architecture”.

We separated the microservice that converts video from the cluster that receives the video. So we separated all of these things: processing user requests from mobile devices does not require big performance. But video conversion, especially when the number of users increases, really needs to be scalable. For example during holidays when load increases dramatically, we could add six additional microservices, and they should handle all of this flow. But at the same time we do not need to increase the capacity of the application, which handles just requests from users. And we get better scalability of the application.

Also a separate cluster was made responsible for reading video. If the load increases specifically for video playback, there is no need to buy a large expensive computer, and you can connect the required number of microservices, that is, increase the number of workers, rather than buy a new plant. This again increases scalability. We have done this, the solution is now being tested on the pre-production server.

We’ve implemented an HLS-streaming cluster. Before, all the converted videos were stored on a hard drive, but now we've moved it all to cloud storage, which is more reliable.

What is memorable about the project?

Valentin said it was an interesting experience to optimize the performance of the old system, which was "dying" from the number of requests and inconsistencies in the architecture.

Working at night? That doesn't usually happen. But once, literally in the middle of the night, the cluster that the guys were making crashed, and we had to immediately address the problems. As it turned out, the error was not in the architecture, but on the provider's side: his network went down. It appeared to be a system test to see if it would work or not. But the connection with the network was quickly restored. Patriotic customers are not going to change the provider - they don't want to withdraw money from France, so no foreign providers.

The main customer is very happy with the way our specialist’s output; the speed and the quality. We hope that the story will continue.