Scale and performance

The problem

You have a launch, a campaign or a seasonal peak coming, and the last one was tense. Response times creep up under load, a dependency falls over, and nobody is quite sure where the limit is until you hit it with real customers watching.

How I approach it

• Measure first: load tests that look like your real peak, plus tracing across services, so we fix the actual bottleneck and not the suspected one.
• Fix the hot paths: service-to-service communication, caching strategy, queries and indexes, and connection and queue limits.
• Make it visible: dashboards and alerts tied to what the customer feels, and a runbook for launch day.
• Rehearse: run the peak before it happens, then be on call with your team when it does.

What it looks like

A fixed-scope project ahead of a known peak, timed to its date. For a top global sportswear brand I worked on product-drop services that handled up to 2.45 million requests per second at peak.

Case study

• A top global sportswear brand · via Inova IT

  Product drops that held at peak

  I worked on the microservices behind limited-edition product drops for a top global sportswear brand: up to 2.45M requests per second and 50 Gbps at peak, expanded to 14+ markets.

Questions

Do we need to move to microservices to scale?

Usually not. Most systems I see are limited by a few hot paths: chatty service calls, missing caches, or a database doing work it shouldn't. Fixing those is faster and cheaper than a new architecture.

What do we get at the end?

Fixes in production, load-test results before and after, and dashboards and alerts so your team can see the next problem coming.

Remote-first, working in EU time zones (CET). On-site visits by arrangement.

All services