An application can look healthy while its customer base grows, then struggle when checkout, reporting and search workloads run simultaneously. Customer count alone does not explain the pressure. The work those customers generate matters more.
That distinction runs through GeekyAnts’ podcast discussion with Ankur Gupta, introduced as a solution architect at OceanBase. This article draws on the episode’s transcript and adds practical considerations for teams assessing architecture and engineering partners.
Customer numbers are not a capacity specification
A product with 100,000 registered customers may have relatively little concurrent activity. A smaller product can face intensive traffic during a sale or reporting deadline.
The transcript highlights how growth introduces different data types and workflows. Transactions, analytics and AI-assisted search place different demands on infrastructure.
A useful capacity assessment therefore starts with:
- Peak concurrent activity and requests per second.
- The mix of reads, writes, searches and background jobs.
- Data volume and concentration around particular customers.
- Response-time expectations for critical journeys.
“Support 100,000 customers” becomes meaningful only when those workload assumptions are explicit.
Diagnose the database before adding infrastructure
Gupta identifies query execution, stored procedures, joins and data distribution as areas that deserve attention.
The practical lesson is to investigate where time is spent before increasing capacity. A slow endpoint might be waiting on an inefficient query, a saturated connection pool or a downstream dependency.
Teams can begin with one critical workflow, such as checkout:
- Trace the request across application and database calls.
- Inspect the slowest queries and their execution plans.
- Compare performance under representative concurrent load.
- Repeat the test after a targeted change.
Additional application instances will not necessarily resolve a bottleneck in a shared database.
Caching helps when its rules are explicit
The discussion presents caching as a way to reduce repeated API and database work.
Product information and other frequently requested data may be suitable candidates. However, a cache introduces decisions about freshness, invalidation and permissions.
A useful design specifies what is cached, how long it remains valid and what happens when many requests arrive after it expires. Data scoped to a customer or tenant must remain isolated.
Caching should reduce measured repetition while preserving the application’s correctness.
Distribution brings trade-offs
Horizontal scaling and partitioning are recurring themes in the transcript. Both can help distribute work, but neither automatically guarantees reliability.
Partition keys deserve particular attention. A design that spreads ordinary traffic evenly may still concentrate a large customer’s activity on one partition.
The discussion also favors consolidating certain transactional and analytical capabilities. That is an option to evaluate, rather than a universal requirement. Consolidation can simplify some integrations; separate systems can provide workload isolation.
The appropriate choice depends on access patterns, consistency requirements, operating costs and the team’s ability to maintain the system.
Architecture needs an economic purpose
One example in the episode concerns an architecture that prioritized analytical capabilities before the business needed them. The broader lesson is that technical investment should follow actual product priorities.
Beyond infrastructure spending, teams should account for maintenance, incident response and specialist operational work.
Cost per successful transaction can be more informative than the monthly hosting bill alone. It connects spending to useful work, especially when retries and failures consume resources without delivering customer value.
Five companies to evaluate for scaling and modernization
The following shortlist reflects relevant published services. It is not an independently verified performance ranking, and inclusion does not establish that a particular team has handled an equivalent workload.
1. GeekyAnts
GeekyAnts publishes services covering scalability planning, observability, cloud infrastructure and production readiness.
Evaluation focus: Request a sample assessment showing how bottlenecks are identified, prioritized and retested. Hosting the source discussion should be distinguished from evidence of project delivery.
2. Thoughtworks
Thoughtworks offers legacy modernization and data platform modernization services.
Evaluation focus: Ask how the proposed team would improve capacity incrementally while preserving existing behavior and limiting migration risk.
3. Dev Technosys
Dev Technosys lists custom software development, consulting and maintenance services.
Evaluation focus: Establish whether performance engineering is explicitly included. Request relevant load-test results, architecture examples and clear ownership of production support.
4. EPAM
EPAM offers engineering modernization and cloud services that address architectural change and scalability.
Evaluation focus: Examine how application, database and infrastructure changes would be coordinated, including migration testing and rollback planning.
5. IBM Consulting
IBM Consulting provides application modernization and cloud transformation services.
Evaluation focus: Clarify platform dependencies, operating costs and the skills the internal team will need after handover
Compare partners using the same workload
A useful evaluation gives each company the same scenario: traffic patterns, data volumes, current constraints and reliability targets.
The requested deliverable should include a diagnosis, a proposed intervention, a repeatable load test and evidence of its effect. This makes proposals easier to compare than broad promises about scalability.
The original discussion is available in “What Actually Breaks When You Go From 100 to 100,000 Customers”. Its central question is a useful starting point: which assumptions stop holding as the workload changes?
Top comments (0)