SCNET · Enterprise IT · Ankara, Türkiye

Sanal Çekirdek

Learn your capacity in a load test, not on campaign day.

High-traffic platforms are designed against the peak scenario, not the average load. Sanal Çekirdek handles scaling, cache layers and back-end resilience within one architecture.

A bottleneck that appears on campaign day is not solved on campaign day. Load testing and real user measurement are work done before the peak.

Peak scenario and capacity plan

Design starts by putting the expected peak into numbers: concurrent users, requests per second and basket or transaction rate. Those numbers come from past campaign data; where none exists they are marked as assumptions and corrected after testing.

  • Every assumed number is explicitly marked as one
  • Peak duration is planned alongside peak height
  • Scaling latency is added to the capacity margin
  • The campaign calendar enters the infrastructure calendar

Cache layers and delivery

The fastest request is the one that never reaches the back end. Edge cache, application cache and the layer in front of the database are designed separately, with invalidation rules written against the content lifecycle.

  • Invalidation rules cover campaign changes too
  • Personalized content is handled in its own layer
  • Cache hit ratio is monitored continuously
  • The cold-start scenario is tested separately

Back-end resilience

What breaks under peak load is usually not the front end but a back-end dependency. Queues, backpressure, circuit breakers and timeout values are part of the design; the system should keep serving partially even while it slows.

  • Timeout values are defined layer by layer
  • Circuit breakers stop a failure from spreading
  • Queues spread a sudden surge over time
  • Partial service beats a full outage

Load testing and real user measurement

Load testing imitates the target scenario; real user measurement shows the experience in the field. Both are used together: the test finds the bottleneck, field measurement confirms the design was right.

  • Test scenarios are derived from real user journeys
  • Field measurement exposes device and network diversity
  • Bottleneck findings become remediation items
  • Results feed the pre-campaign decision meeting

How we work

  1. Define the peak scenario in numbers
  2. Build the cache and scaling architecture
  3. Apply back-end resilience patterns
  4. Run load tests against the target scenario
  5. Confirm with field measurement and correct

How success is measured

  • The peak scenario was met under test
  • Cache hit ratio sits above target
  • Partial service continues during slowdowns
  • Field measurement is consistent with test results

Frequently asked questions

Isn't auto-scaling enough?

Not on its own. Scaling has latency and a sudden peak can arrive faster than that; scaling one tier also does not enlarge fixed capacity further back. Capacity margin and caching are needed for that reason.

Can we load test in production?

Testing in the closest environment to production is preferred; if it must happen in production, traffic separation, data isolation and a stop switch have to be ready beforehand.

How much lead time before a campaign?

Enough that findings can still be fixed. Without a window for remediation and a retest between the test and the campaign, the test has only delivered bad news early.

Share your campaign calendar; we will turn the peak into numbers and plan the test window together.

Let's size your peak scenario