Data4Sales

Data4Sales is a smart marketing platform that helps e-commerce stores build customer loyalty and create targeted campaigns. It runs on AWS, and its infrastructure grew at whatever pace the product demanded.

That growth had a cost that wasn’t obvious at first. Everything had been created by hand. There was no test environment separate from production, so every change reached live operations without passing through anywhere else first. Deploys weren’t automated, no alerts were set up, and problems were caught late. Cloud spend was hard to predict.

The team knew it had to act. What it lacked was a map: which problems existed, which were critical, and where to start. So the first step wasn’t to build. It was to diagnose.

The assessment covered six areas: cloud infrastructure, CI/CD, security, observability, costs, and operating model. We reviewed the AWS account, repositories, pipelines, permissions, metrics, and billing, and interviewed the technical leads.

We classified each finding by severity and against the pillars of AWS Well-Architected, AWS’s framework of best practices. From there we built a maturity baseline to measure progress, and a concrete remediation plan.

Databases first. We migrated the main cluster from MySQL 5.7 to 8.0 with a blue/green deployment: the new version runs in parallel and traffic only switches over once it’s ready. Beforehand, the Data4Sales team validated its application against a copy. The PostgreSQL database, which ran on an unmanaged server, moved to RDS and from version 13 to 17. Production databases are now reachable only from the private network.

Infrastructure written as code. We designed a segmented network and created the infrastructure repository in Terraform and Terragrunt, with modules for networking, Kubernetes, permissions, and image registries. Infrastructure that lives in code can be reviewed, repeated, and extended, instead of depending on what someone configured by hand. On that foundation we set up an EKS staging cluster and moved DNS to Route 53.

The shift: Support moved to the front. Halfway through the project, the priority became Support, a new Data4Sales product. We built its staging and production from code, plus a CI/CD flow with temporary environments per pull request: every change can be tested in isolation before it’s merged. Then we brought the same setup to the main platform.

Deploys without downtime. We scaled capacity up ahead of high-traffic dates and back down afterward. We moved deploys to their own tunnel per run with AWS Systems Manager, so several can run at once without blocking each other. With that change we removed the downtime window that Support deploys used to leave.

Data4Sales went from having no test environments to having staging separate from production. Its teams test every change in its own environment before merging it, and new infrastructure is defined in code.

Deploys run from CI, several services deploy at once without blocking each other, and production databases run supported versions, reachable only from the private network.

What’s next. The work continues. The next stage is bringing the main platform’s production environment onto the same setup.