About the client
Our client is a B2B marketing technology platform that helps revenue teams build hyper-targeted audiences and activate precision ad campaigns across various social media platforms. Their platform ran on Heroku, a managed cloud platform popular among startups for its ease of use and lightweight approach to infrastructure management. At scale, Heroku's limitations in control, cost, and customization began working against them. Additionally, the Observability was virtually non-existent, and the data layer powering their campaign engine wasn't built for the query patterns the product demanded. The platform needed a complete revamp.
Business impact
Faster Releases
75%+ faster
Time to production dropped from 40+ minutes to under 7. Every merge ships automatically.
Improved Reliability
99%+ uptime
Autoscaling, automatic rollback on every deployment. Highly resilient architecture. No more random failures disrupting production.
Full-Stack Observability
MTTR Hours → minutes
MTTR dropped from hours to minutes. Engineer finds the root cause with full stack Observability and fixes it in minutes.
The challenge
The team wanted to migrate to a new platform and a more reliable hyperscale cloud to improve developer experience, scalability, and future growth without introducing complexity. The engineering leadership were concerned about the added complexity that might come with Kubernetes adoption and the cost of observability, which can sometimes spiral out of control.
Immediate concerns included:
- Reliability and Scalability: With an increasing number of users and growing complexity of asynchronous workflows, the current Heroku platform was insufficient. It provided limited control and options.
- Cost: Platform costs were rising and wouldn't be sustainable at scale, with limited ability to optimize. Additionally, the team was concerned about the cost of observability and Kubernetes adoption.
- Observability: No APM, no distributed tracing, no alerts—engineers were manually searching logs every time something broke.
- Performance: Campaign filtering queries on BigQuery weren't built for low-latency, filter-heavy reads, and running analytics on a separate cloud added billing and transfer overhead due to egress costs.
Modern platform engineering built for developer speed and operational reliability
We conducted a systematic analysis of each pain point in its respective domain and proposed a modern platform engineering solution that addressed them all. Our solution was derived after comprehensive POCs and benchmarking of multiple options in each domain, providing a clear path to the best possible solution for the client's needs.
Cloud selection: Why AWS over GCP
The team was already using multiple clouds for various services. Heroku for running containers, AWS for S3 storage and route 53 (DNS), and GCP for running the BigQuery for analytics. The new platform runs on Amazon Web Services with Kubernetes as the container orchestration layer to run services reliably at scale. AWS was selected over GCP through a structured internal evaluation across multiple factors. The deciding factors were developer familiarity as they had stronger existing comfort with AWS and enterprise support as our main goal was to build a platform that has minimum developer friction and ease of use. This consolidation helped in reducing the cost.
Why Kubernetes
We evaluated alternatives like AWS ECS, but Kubernetes was the clear choice for a team building for the long term. The reasons are straightforward:
- Better integration and availability of tools
- Portability and no vendor lock-in
- Most modern developer tooling is Kubernetes-native
- Industry standard for cloud-native applications across major cloud providers
Making Kubernetes simple for developers
The major challenge with Kubernetes is its complexity and cognitive load. It can become overwhelming for developers who aren't familiar with it. So we built an internal developer platform on top of Kubernetes that abstracts it almost entirely. An engineer defines a new service specification, and a translator converts this specification into Kubernetes manifests in the CI pipeline while adding meaningful defaults such as resource limits, health checks, and replicas. All relevant resources required to deploy an application are created automatically, including Kubernetes resources, observability specifications, OpenTelemetry pipeline, alerts, and dashboards. For continuous deployments, we use a GitOps-based approach where ArgoCD syncs the translated manifests to the cluster. The result is a fully automated self-service platform that reduces friction when deploying new services.
Golden path for service onboarding
Every new service follows the same standardized route: service specification, a GitHub pipeline using a library of reusable components, observability, and fully automated CD to production with a Slack-driven workflow for human-in-the-loop production deployment approvals. This ensures consistency and faster onboarding of new services, reducing the time to deploy a new service from a day to minutes.
Faster releases with a fully autonomous CI/CD pipeline
- Every code merge triggers a fully automated pipeline: build, test, deploy to staging, smoke test, promote to production—with no manual steps and no release managers
- Time to production reduced from over 40 minutes to under 7 minutes, enabling faster feedback on code changes, more releases per day, and measurable improvements in developer productivity
- More reliable releases through 100% test coverage and staged rollouts, with quality gates at every stage and automatic rollback if any check fails
- Infrastructure provisioned via Terraform—every environment is reproducible, version-controlled, and auditable
- Aligned with SOC 2 requirements from day one: secrets stored in AWS Secrets Manager and injected dynamically at runtime, never hardcoded
- ArgoCD syncs the desired state of the cluster with the actual state and automatically reconciles any drift
Full-stack observability
The observability stack covers the full surface: APM, distributed traces, logs, and metrics, all instrumented through OpenTelemetry, keeping data portable and the team independent of any single vendor's instrumentation format. To simplify OpenTelemetry adoption, we built a centralized library for all services to consume in a standardized way. This ensures consistency and reduces the effort required to instrument new services.
We selected SigNoz SaaS after a structured evaluation of multiple platforms. It was chosen for its cost-effectiveness, features required for our use case, and low operational burden. The team wanted a managed service, not another system to maintain. The SigNoz team was very responsive to our feedback, incorporated our requirements in a timely manner, and provided support whenever needed.
What the observability stack delivers:
- Application Performance Monitoring (APM) across all services -- response times, error rates, throughput, and service health in a single view
- Distributed tracing that follows a single request across every service it touches, showing exactly where a failure or slowdown originates
- Centralized log management, replacing ad hoc searches across fragmented, service-specific log streams
- Anomaly detection and alerting routed through PagerDuty for structured incident response
- SLO monitoring with SLI/SLO tracking, incident workflows via Incident.io, and post-mortems in Notion
- MTTR reduction—incidents that previously took hours to diagnose are now resolved in minutes, with root causes visible to any engineer on the team
- Full production visibility into traffic patterns, weak areas, and improvement opportunities across infrastructure and application layers
Data migration from BigQuery to Clickhouse
Campaign filtering engine in the product demands low-latency query performance. We benchmarked ClickHouse against BigQuery and Hydra (PostgreSQL based). ClickHouse delivered 10x better data compression ratios, significantly faster performance on filter-heavy queries, the ability to run entirely within AWS VPC, consolidating the full stack onto a single cloud provider and lower overall cost.
The migration was executed in three stages: BigQuery → Amazon S3 → ClickHouse Cloud, with a private VPC connection keeping data transfer secure and egress costs minimal. The result is a faster, leaner analytics layer on the same cloud as the rest of the platform, fewer vendors, simpler operations, and audience search results that feel genuinely instant.
Results
The team now operates on infrastructure built for scale, not inherited from an early-stage workaround. Developer productivity is up, time to production dropped by 75% and every release is automated. The platform is reliable by design: autoscaling, automatic rollbacks, and self-healing infrastructure have eliminated the random outages that were disrupting production. And with full-stack observability in place, any engineer can identify the root cause of an incident in minutes without manual log searches.
Is your Infrastructure slowing your engineers down?
If your team is spending time working around deployments instead of shipping product, there is a better way. Talk to us about platform engineering built for developer velocity.
