Living with Salesforce Platform Limits: A Booking Engine Optimized in 3 Weeks
Expo Mexico's booking engine, the core of its event-space business, kept collapsing under everyday data loads. Instead of a costly migration or rewrite, Hikko traced the real problem to implementation debt, refactored the critical Apex, and returned a stable, standards-aligned module ready to grow, in less than 30 days.

Introduction
Expo Mexico runs on bookings. As a company that manages event-space and venue rentals, its entire commercial operation flows through one module on Salesforce, the system that captures, processes, and manages every reservation. It is the tool the team touches every single day, and it sits at the center of how the business makes money.
The Challenge
Businesses grow, and the software underneath them has to grow with them. Expo Mexico's booking volume had climbed steadily, and the module that had comfortably handled the load a couple of years earlier was beginning to feel the pressure. This is a normal moment in the life of any Salesforce solution: code that performs well at one volume starts to tighten as the business scales and transactions multiply. It happens to good solutions.
The specific pressure was against Salesforce's governor limits, the platform's defined ceilings on how much processing any single operation can do. Every solution built on Salesforce lives inside those limits. As Expo Mexico's reservations grew, the booking module was consuming that headroom faster than it needed to, and the margin before those ceilings started to matter was getting thinner. For a business where booking is the operation, protecting that headroom is not a technical nicety, it is how you keep revenue flowing as the company grows.
The Analysis
Before proposing a single change, Hikko measured. We got access to the sandbox and analyzed how the module actually consumed platform limits: which operations drove the most usage, where the headroom was being spent, and how that curve would behave as volume kept climbing.
The picture was clear, and it pointed to real headroom to recover. Apex could handle Expo Mexico's workload comfortably. The opportunity was in how the solution used the platform: database operations running inside loops, queries repeated across events, and logic processing one record at a time where it could process many at once. Each pattern is small on its own. Together, they spent governor-limit capacity faster than the workload required. Reading that accurately, before recommending anything, is the difference between paying for a new platform and freeing the room you already have.
The Decision
Measuring first led to a clear decision: optimize the existing module on Apex, rather than migrate it to another platform or rewrite it from scratch. The business logic was sound and the foundation was solid, so a rewrite or a migration would have meant months rebuilding something Expo Mexico already had, at real cost, with no gain in what the users actually experienced.
We chose to optimize. Same platform, same workflow, more headroom. From the outside, Expo Mexico's team would book and manage events exactly as before. Underneath, the engine would have far more room to grow into. That decision is what saved the client months of work and a good part of the budget.
What We Delivered
- More headroom under the governor limits. We refactored the classes driving the highest consumption, moved database operations out of loops, and redesigned methods to process reservations in batches instead of one record at a time. This is core Salesforce craft, bulkification and DML kept outside of loops, and it cut platform-limit usage sharply.
- A leaner codebase. We consolidated repeated queries and duplicated logic, reducing the number of queries fired on every event and bringing the module in line with Apex best practices.
- Confidence that nothing changed for the user. We reviewed related dependencies and automations, ran technical testing, and validated behavior with the business team, confirming the workflow was preserved end to end.
- A base ready to scale. We delivered updated technical documentation and clear recommendations for future evolution, so new features can be built on top of a module with room to grow.
The Result
In about three weeks, analysis and development included, Expo Mexico's booking engine was running on a clean, best-practice foundation with meaningful headroom under the platform's limits. Zero downtime. Zero change to how the team works. The same module they touch every day, now with far more room to absorb the growth ahead.
The point was never to replace what worked. It was to read the platform accurately, spend effort exactly where it moved the needle, and hand the business more capacity to keep scaling on the investment it already had.
How It Stays Healthy
Headroom is something you keep, not something you buy once. To protect it as Expo Mexico grows, Hikko provides ongoing technical governance: a monthly technical committee, preventive code review before new changes ship, and continuous monitoring of platform-limit consumption. The module keeps pace with the business instead of tightening against it again.
The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of Hikko.



