E-commerce Server Hosting

Why does E-ticaret need a server?

Two things decide. First the database: products, orders and stock movements live in it, and query latency shows up directly in page load time, which is where NVMe storage makes a difference. Second continuity: if the integration software runs every minute, the server has to be up every minute. During campaigns peak load rises well above the average, and sizing for the average creates problems on exactly those days.

Recommended resources

These values match the VDS plan tiers in our catalogue; the exact price is calculated in the configurator.

Where slowness comes from: database, cache, storage

An e-commerce page rarely slows down because the CPU ran out. The chain usually runs like this: a product list query runs without an index, the database goes to disk, storage latency is added to query time and query time to page load. On MySQL and MariaDB the single biggest win is the InnoDB buffer pool: as long as your working set fits in memory, queries never touch the disk at all. On a machine dominated by the database, setting the buffer pool to somewhere between 50 and 70 percent of total RAM is a common starting point — about 4-5 GB on a server with 8 GB. The next three steps are enabling OPcache on the PHP side, putting repeated queries behind a cache such as Redis, and resizing product images once and storing the result. When those are exhausted, storage is what is left; because every Datafex plan uses NVMe SSD, latency there is markedly lower than on a SATA-based setup. Do not run the sequence backwards: replacing storage before adding an index is the most expensive possible fix.

Planning capacity for campaign days

On days like 11.11, Black Friday and seasonal sales, peak traffic climbs to several times a normal day and the climb happens over minutes, not hours. If you sized for the average, the problem arrives exactly during the hours you were going to sell. Three things help. First, measure: run a concurrency test before the campaign and see which resource saturates first — it is usually not the CPU but the database connection pool or the PHP-FPM process count, and both are configuration rather than hardware. Second, upgrade early: plan the resource increase for the week before the campaign rather than the day itself, so you get to exercise the new configuration under real traffic. Third, thin out scheduled jobs: if stock synchronisation, report generation and email sending all fire at peak hour, they consume between themselves the capacity meant for customers. Protecting those jobs with a lock file also stops a second run from starting before the first has finished.

Setup steps

1. 1Install the server with an Ubuntu 22.04 or Debian 12 template.
2. 2Install a web server, PHP or Node.js, and MySQL/MariaDB.
3. 3Point the domain at the server, install an SSL certificate and redirect HTTP to HTTPS.
4. 4Install your store software or integration application.
5. 5Tune the PHP-FPM process count and the database buffer pool to the server's RAM; the defaults were written for much smaller machines.
6. 6Schedule stock synchronisation as a cron job and use a lock so runs cannot overlap.
7. 7Schedule daily database backups and keep one copy off the server; order data cannot be recovered otherwise.

Common mistakes

• Sizing for a normal day's traffic. On campaign days peak load runs far above the average.
• Not planning for the database. It runs on the same machine and belongs in the storage and RAM budget.
• Synchronising stock too rarely. Lagging stock means you keep selling what is already sold.
• Leaving scheduled jobs unlocked. A new run starts before the previous one finished, and overlapping jobs fill the server by themselves.
• Storing card data in your own database. Card details belong with the payment provider; keeping them on your server takes on a burden you do not have to carry.
• Keeping the backup on the same server. Lose the disk and you lose the backup with it.

What is included at Datafex

Frequently Asked Questions

Can I host my store here as well?

Yes. You can run your own store software on a VDS. If you only run marketplace integrations, a smaller plan is enough.

Why a VDS instead of shared hosting?

On shared hosting resources are shared with other customers and cron frequency is usually limited. Both limits cause problems if you run integrations.

How much RAM does a catalogue of a given size need?

It is not only product count that decides but concurrent visitors. A catalogue of a few thousand products with one marketplace integration runs on 4 GB. Tens of thousands of products, multi-channel synchronisation and regular campaign traffic move you into the 8-16 GB band, where what really consumes RAM is the database buffer pool.

Does the server have to be in Turkey?

It is not mandatory, but there are two practical reasons. First, latency: if most of your customers are in Turkey, a domestic server lowers page load time. Second, administrative: transferring personal data abroad is subject to specific conditions, and keeping the data in-country removes the need to deal with them. Datafex servers are in the DGN data centre in Bursa.

Can I temporarily scale up for a campaign?

Resource changes are made through the configurator. The safe sequence is this: scale up a week before the campaign, exercise the new configuration under real traffic that week, and only go into the campaign on it if the results hold. Leaving the test to the morning of the campaign means finding the problem at the worst possible moment.