Technical Lessons from Scaling Artmeet to 20k Users

Starting Simple

When we launched Artmeet in 2021, the architecture was straightforward: a CodeIgniter monolith with MySQL, running on a single AWS EC2 instance. No microservices, no message queues, no fancy infrastructure.

And that was exactly right for the stage we were at.

The First Scaling Pain

Our first real scaling challenge came when we launched design competitions. Suddenly, we had hundreds of concurrent users voting, commenting, and uploading designs. The monolith held up, but database queries started slowing down.

Lesson: Add Redis early. We should have introduced caching from the start, not as a reaction to slow queries. A simple Redis layer for hot data (competition leaderboards, frequently accessed profiles) cut our average response time by 60%.

Multi-Tenancy Complexities

Artmeet served four distinct user types: designers, recruiters, judges, and administrators. Each had different views of the same data, different permission levels, and different workflows.

What worked:

• Role-based middleware that cleanly separated concerns
• Shared data models with role-specific query scopes
• A unified notification system that adapted content per role

What didn't:

• Trying to build separate dashboards too early — we should have started with one flexible dashboard and specialized later

The ATS Challenge

Building a custom Applicant Tracking System was the most complex feature. The candidate pipeline had to support:

• Multiple stages (customizable per recruiter)
• Bulk actions across hundreds of applicants
• Interview scheduling with timezone handling
• Email notifications at each stage transition

Lesson: State machines save lives. We modeled the candidate pipeline as a finite state machine, which made transitions predictable, auditable, and debuggable.

Cross-Country Expansion

Expanding from Malaysia to Singapore and the Philippines introduced challenges I didn't anticipate:

• Localization — Not just language, but currency, date formats, and cultural norms around hiring
• Data residency — Different expectations around where user data lives
• Performance — Users in the Philippines experienced higher latency; we added CloudFront distribution

What I'd Do Differently

If I were building Artmeet from scratch today:

1. Start with TypeScript — We used vanilla PHP/JavaScript. Type safety would have prevented entire categories of bugs.
2. Invest in observability early — We added proper logging and monitoring too late. By the time we had dashboards, we'd already lost debugging context for several production issues.
3. API-first architecture — We built the frontend and backend tightly coupled. An API-first approach would have made the later mobile app much easier.

The Biggest Lesson

Technology is the easy part. The hard part is understanding what to build, for whom, and when to ship "good enough" versus when to invest in quality. Three years of Artmeet taught me that the best architecture is the one that lets you learn from users as fast as possible.