A website for a team that organizes community programs may look like a simple job at first: programs, dates, venues, a few photo galleries. Then come the users, the community features, the automations, the permission rules, the external services, and thousands of visitors arriving at a website whose database tables hold millions of rows.
We have been developing a community event platform like this for more than ten years, from the very first line, working out the features together with its founder.
The difficulty lies in the connections
The platform was originally built to promote programs, events and parties, but registered users can also connect with each other on it. Events can be described in great detail: there's on-site RSVP, a ticket purchase option tied to it that only those who signed up can see, attendance limits, plus-ones, a “what to bring” list and a comment wall. Galleries and memories are attached to events afterwards, users can join groups, and the system can send them targeted messages through its own newsletter tool.
None of these features is complicated on its own. The difficulty comes from the fact that they're all connected: an event's visibility depends on the organizer, group membership and the connections between users, and an attendance limit affects both sign-ups and ticket sales. Permission management, meaning who can see whom and what they can see of them, became one of the most complex parts of the system.
The data model talks back eventually
What works well with a few thousand records won't necessarily work with millions. There were periods when complex queries put a heavy load on the database. The solution then wasn't a big rewrite but continuous optimization: where it was justified, we denormalized data and introduced precomputed views, so that frequently read information doesn't have to be reassembled on every request.
Besides designing the database structure, one of the most interesting parts of the work was building the scheduled background jobs. Events change state on their own, from announcement to closing, and this has to work reliably even when nobody is watching.
Ten years, several rounds of modernization
The platform is a custom, Symfony-based build. Over ten years, we've carried out several rounds of modernization, and at least a third of the external dependencies have been replaced. A replacement like this is rarely a simple version upgrade: replacing a user management or mailing component touches many parts of the system. Meanwhile, external services, such as social media APIs, change too, and those changes have to be kept up with.
Public platforms with many users are attractive targets for attackers too. We had to deal with denial-of-service attacks, account takeover attempts, and attempts at automated data scraping and vulnerability probing.
Meanwhile, the system has to keep running
A live community platform can't be shut down for a few months while we put it in order. Development and operations run in parallel: new features get built, small bugs surface, and modernization has to happen in a way that lets users keep using the site without disruption.
What would we do differently today?
Ten years teach you a few things. Today we would design fewer dependencies that cut across modules, and try to keep complexity within the boundaries of individual modules, so they can be reworked independently later. Permission management is a good example: today we might design it more simply, because over time its flexibility also showed up in the cost of further development.
And meanwhile, business needs change too
With a platform that runs for years, business needs keep changing. In this example, the focus of the user experience is shifting more and more toward mobile, the website's role is changing too, and the system behind it has to adapt to that as well.
Starting small is easy
At ENEOPT, we build systems that can still adapt years later to whatever they serve. If your website is starting to outgrow its limits as users, features and connections keep multiplying, let's talk before the data model starts talking back. Starting small is easy. Growing big while staying operational: that's the interesting part.