Bijna twee jaar geleden begon ik bij Infowijs als lead developer. Inmiddels hebben we een grote hoeveelheid kennis vergaard en verbeteringen doorgevoerd. Daarom leek mij dit het goede moment om in een blog post te reflecteren op deze reis, en scholen en ons bredere netwerk een goede achtergrond te geven over de technische keuzes die we hebben gemaakt en de lessen die we hebben geleerd. Het artikel is origineel gepubliceerd op HackerNoon en is daarom in het engels geschreven.

Back in the days

The history of our company (Infowijs) started when our two founders Thom and Tobias, who met in university, were working as freelancers. Thom is a designer with a background in Communication Science and Tobias is a marketeer/business developer with a background in (Growth) Marketing and Political Science. At some point, Thom was asked by some Dutch schools to renew their websites.

A recurring part of those projects was creating or updating the school guides, containing all sorts of important information for parents. At a certain point, Thom and Tobias saw an opportunity and came up with a plan to actually digitise those school guides.

Up to that moment schools created and printed their guides before the start of a new school year (and to be fair, many schools still do). Any changes would only be updated in the next cycle. And there’s a mismatch with user expectations; we are so used to continuously being updated with new and changing information, that an online/digital solution seems to be the logical next step.

After some initial tryouts, which were co-created together with a handful of Dutch secondary schools, the first digital school guides were created with WordPress. The product was (and still is) called Schoolwiki. For the first couple of years, this worked well enough, however as with every MVP, a next step was needed to be made. Plans grew bigger and schools requested more and more features over time. One of those requests was for a more real-time communication tool.

Simultaneously a bigger question grew in the minds of our founders, what if we could make a private chat app where teachers and parents could talk, send requests and even fill out inquiries digitally?

And so Hoy was born.

We continue

As more and more schools started using Schoolwiki, the backlog grew and the founders started selling the product more seriously as a company instead of freelancers. This led to their search for a developer to join their founding team. Someone who could help them to develop more robust features and preferably someone with some knowledge of the internals of Dutch school administrations systems. The companies building this administration software tend to have a closed system and are making it very difficult to connect with.

That’s when they met Thomas. A tech guy and a pragmatic developer who hacked, while in school, onto one of those administration systems. After joining the founding team of Infowijs he grew the tech side of our company to a point where both Schoolwiki and Hoy were running on a PHP framework he’d created over the years.

🧑‍💻 His PHP framework was a Laravel-inspired, project, using Twig and/or React for rendering its web applications while being deployed on AWS EC2’s and being connected to a RDS-powered MySQL database.

When I joined the company 2 years ago, Thomas had the opportunity to work full-time in another startup he founded (NearSt) and so Infowijs was looking for a new Lead Developer. The mission was to scale up the development team and transition the existing applications to a more scalable approach to support the further growth of the company.

Now

This brings us to today. Currently, we have a monthly load of approximately 2 million requests from our users. This number is growing exponentially as our sales grow fast. Every month, we add a dozen new schools. But apart from scaling our AWS tech stack and burning through our credit cards, there wasn’t much to scale further with the existing platform. There were limits on the database processing side, and our PHP framework has a limited number of requests it can handle per minute.

Therefore I’ve decided 2 years ago to create an entirely new architecture to support our applications and the company’s growth.

We chose to create this new platform with Vert.x written in Kotlin and planned to run it on AWS ECS with Fargate instances. This way we can run fast applications that scale both horizontally and vertically at minimum costs. Together with our new codebase, we’ve decided to switch the main database of the new platform to Postgres instead of MySQL. This gives us lots of benefits in speed as well as the ability to have both a relational database and proper support for JSON storage (like a NoSQL database).

You set it up as a microservice-based architecture where each domain lives in its own isolated services. Services only talk with their own set of tables and databases and cross-communication is only done over the EventBus. Vert.x is based on the principle of verticles. A verticle is basically a lightweight actor executing an isolated unit of work, that can scale independently. It’s a simple as your microservice architecture down to the level of your codebase. Where your domains are separated on service level, your units of work are separated in verticals.

Vert.x offers us flexible and easy asynchronous programming especially in combination with Kotlin Coroutines. In some sense, it’s somewhat comparable with Node.js, for those unfamiliar with Vert.x and Kotlin (Coroutines).

However, since it runs on the JVM it empowers all its great performance benefits. This way, even in the cloud, we can handle tenfold the requests per minute, more than we ever could do with any other stack, and especially our previous PHP stack.

At the moment of writing, we are in the middle of migrating our platform and even though we aren’t even halfway, we’ve already seen some interesting results that prove we made the right decision going forward.

Right now, we process 2.5 million daily requests while all the services are running on the cheapest Fargate and Postgres instances. We haven’t seen any spikes in our system even on “busy” days. While our old platform, with a massively upgraded MySQL RDS database, is having a really hard time with 99% CPU usage. At those times, processing basically the same data in different domains of our platform, our new Postgres database barely hits 20% CPU peaks while running on the cheapest tier. The TechEmpower benchmark tests of Vert.x with Postgres are actually quite accurate in a production environment.

Our Future

In the coming year or so we will continue to move more domains from our old platform to the new one. So far we’ve moved 2 main domains of our systems to the new architecture, while also developing new (web) clients to support them with both new designs and more performant APIs.

We have high hopes to scale up our small, distributed, Netherlands-based development team in the coming years and be the best in our field. Providing the best digital communication tools for Dutch schools.