Cloud services for a scalable pharmacy ecommerce

An online store does not need the same infrastructure on a Tuesday in February as it does on the day of a campaign. The problem with classic hosting is that it forces a choice: either size for the worst day of the year and pay that size all year, or save money and hope the peak never comes.

This pharmacy ecommerce was migrated to AWS with auto-scaling and load balancing to handle demand peaks, a CDN to serve the catalog, a managed database, backups, monitoring and resource tuning focused on the bill. After the project the infrastructure supports 200% more traffic and cloud costs dropped 45%.

The challenge: hosting sized for the worst day of the year

A health ecommerce has two particularities that sit badly with rigid infrastructure: demand is highly seasonal and the service cannot afford outages. Both point to the same place: the infrastructure has to be elastic and watched.

Peaks are not negotiable

When a campaign or a strong season arrives, traffic jumps. With fixed servers, that day becomes a countdown: if the store holds, fine; if not, every minute down is orders going to competitors and customers who do not come back.

The bill grew with the infrastructure

The usual solution — over-sizing to stay calm — is paid every month, including when it is not needed. Cost stopped being tied to usage and became tied to fear, which is the worst way to buy infrastructure.

A health store cannot go down

In a pharmacy ecommerce there are ongoing treatment orders: if the store fails, you do not just lose a one-off sale, you lose the trust of a customer who buys the same thing every month. And the database — orders, stock, prices — is where a failure hurts most.

The solution: migrating to AWS with auto-scaling and CDN

The ecommerce was migrated to AWS and the infrastructure was reorganised around real usage: capacity that grows and shrinks with traffic, static content served from the edge and a managed database that stops being a single point of worry.

Auto-scaling and load balancing

Capacity is spread across several servers and grows automatically when demand rises, coming back down afterwards. That is what turns the peak into something predictable instead of a risk: the infrastructure is ready for the big day without paying for it all year.

CDN and managed database

The CDN serves images and static content from the point closest to the visitor, which in a catalog with product photos is the difference between a page that appears and one that keeps you waiting. The database becomes managed: backups, replicas and updates stop depending on someone remembering them.

Backups and monitoring

Backups are scheduled and tested, and monitoring warns before the customer notices the problem. For a store that sells daily, finding out about an outage from a buyer's message is the most expensive way to discover it.

How we did it in more than three months

The project had two clear phases: first migrate without cutting sales, then tune the bill. Migrating is a change of place; optimising is fine-tuning the size of each resource, and that can only be done well with real usage data.

Migrating without cutting sales

The migration was done in stages with the store running, checking that orders, stock and prices still matched at every step. In an ecommerce there is no maintenance window: a store that shuts down to migrate loses exactly what it is trying to protect.

Tuning the bill after migrating

With the store already in the cloud and real consumption data, the resources were reviewed: instance sizes, storage, transfer and services that were being paid for without being used. That tuning explains a good part of the saving, and it cannot be done before having data.

Results

The project was delivered with the store on AWS, auto-scaling and the CDN running, the managed database and monitoring watching over it. These were the needs and how they were solved:

The measured results of the project: the infrastructure supports 200% more traffic and cloud costs dropped 45%. Both figures together are the point of a well-done migration: more available capacity and less money spent, because infrastructure stopped being bought by eye.

What a growing ecommerce needs

If your store sells more and more and the infrastructure is starting to be a problem, these are the points that decide whether it holds up:

• Elastic capacity, to grow during the peak without paying for the peak all year.
• Load balancing across servers, which is what stops a single machine being the store's limit.
• A CDN for images and static files, because in a visual catalog it decides perceived speed.
• A managed database, with backups and replicas that do not depend on anyone's memory.
• Monitoring with alerts, so you find out before the customer does.
• A regular review of the bill, because over-sized resources stay there forever.

If your store falls short during peaks or you pay for infrastructure you do not use, our cloud services page explains how we work, and you can write to us to go through it together.

Frequently asked questions

When should an ecommerce migrate to the cloud?

When demand stops being predictable or the hosting bill grows out of control. Classic hosting forces you to size for the worst day of the year and pay that size for all 365; the cloud lets you grow during the peak and scale back afterwards, which is exactly what a store running campaigns needs.

What does auto-scaling add to an online store?

Paying for what you use. The infrastructure adds capacity when traffic arrives and removes it when it leaves, so the peak stops being a risk and stops being a fixed cost. In pharmacy those peaks are seasonal and predictable, but previously you had to be ready all year round.

Why a managed database?

Because the most delicate part of a store is the database: orders, stock and prices. With a managed database, backups, replicas and updates stop depending on someone remembering them, and recovery becomes a tested procedure instead of a hope.

How long does migrating an ecommerce to the cloud take?

This project took more than three months. The schedule is set by the migration itself, auto-scaling and load balancing, the CDN, the managed database, backups, monitoring and resource tuning to reduce the bill.