Local, in-process flag evaluation means feature checks run inside Samsung Ads' latency-sensitive bidding path without adding network risk , proven against real production traffic before any enterprise commitment.
Decoupling deploy from release cut mean time to restore from a multi-pod rollback across data centers to disabling a single flag — and drove down change failure rate, a DORA metric the team now actively tracks.
Standardizing on one platform shifted the conversation from "how are we deploying this?" to "how do we want to release this?" — with product teams now managing rollouts directly through the Unleash API.
We wanted a platform that could run within our own infrastructure and align with our data requirements. Our bidding systems operate at very high throughput and are latency sensitive, so feature evaluation needed to be extremely fast and reliable, and not introduce additional risk into the request path
Rohan Deshpande
Staff Software Engineer, Samsung Ads
Samsung Ads builds the advertising systems that deliver ad experiences on Samsung TVs. The bidding systems behind those experiences run at very high throughput and are latency sensitive, so anything that touches the request path has to be fast and reliable. As the engineering organization grew, every team was solving feature rollout and experimentation in its own way, with no shared platform, no consistent governance, and limited visibility.
Rohan Deshpande, a staff software engineer on the ad experience team, led the effort to fix that. The result is a standardized FeatureOps practice on Unleash that now runs across Samsung Ads’ back end and front end systems.
Samsung Ads had no standardized feature management or experimentation platform. As teams and systems scaled, that gap got expensive. The same problems were being solved repeatedly, in incompatible ways, with no common governance or visibility.
The team wanted a single platform that delivered four things: controlled feature rollouts, experimentation, a clean separation of deployment from release, and performance that would hold up under their traffic.
“We wanted to move away from individual teams solving feature rollout and experimentation challenges in different ways, and instead provide a common platform with consistent practices, governance, and visibility.” — Rohan Deshpande, Staff Software Engineer, Samsung Ads
For an ads platform, two requirements were non-negotiable. The data had to stay inside Samsung’s own infrastructure, and feature evaluation had to be fast enough to sit in a latency-sensitive bidding path without adding risk.
Samsung Ads ran a structured evaluation in 2023, comparing GrowthBook, AWS AppConfig, Optimizely, LaunchDarkly, and Unleash across feature management, experimentation, SDK availability, developer experience, scalability, and enterprise readiness.
Two criteria carried the most weight.
“We wanted a platform that could run within our own infrastructure and align with our data requirements. Our bidding systems operate at very high throughput and are latency sensitive, so feature evaluation needed to be extremely fast and reliable, and not introduce additional risk into the request path.” — Rohan Deshpande, Samsung Ads
Unleash’s local, in-application SDK evaluation answered both. Sensitive data stayed in Samsung’s infrastructure, and flag checks happened in-process rather than over a network hop, so they could live safely inside the bidding path.
The deciding factor was that the team did not have to take that on faith. They proved it in production.
“Instead of making a decision based only on feature comparisons or proofs of concept, we started with the open source version, integrated it with our real production workloads. One of the key use cases was rolling out our new Golang-based bidding system, where performance, stability, and reliability really mattered.” — Rohan Deshpande, Samsung Ads
Once that worked at their scale, moving to Unleash Enterprise was an easy decision.
The implementation followed the same pattern that won the evaluation: prove it small, then scale it.
The SRE team productionized Unleash Enterprise using the Helm charts, deployed inside Samsung’s own infrastructure. Production rollout took roughly two months, after which adoption spread gradually to the bidding services, back end platforms, and front end applications.
As with any new platform, the harder part was people, not pipelines. Samsung Ads invested heavily in enablement: brown bag sessions to share patterns and lessons learned, and on-site time with the Unleash team at the company’s Mountain View office to socialize the platform across engineering. Production proof plus education plus partnership built the trust that drove adoption.
That is when the real shift happened.
“Initially, many engineers looked at feature flags as simple on/off switches. As adoption grew, the conversation changed from ‘how are we deploying this feature’ to ‘how do we want to release this feature.’ Teams started thinking about rollout strategies, user targeting, and monitoring. The platform didn’t just change our release process, it changed how we approached software in production.” — Rohan Deshpande, Samsung Ads
Before Unleash, deployment and feature availability were tied together, so a bad change meant rolling back an application version. At Samsung’s scale, that meant minutes of elevated error rates across pods and data centers while the rollback propagated.
“With Unleash, teams can deploy, gradually enable features for a controlled audience, monitor the behavior, and increase rollout as confidence grows. This helps reduce the blast radius if an issue occurs.” — Rohan Deshpande, Samsung Ads
When something does go wrong, recovery no longer waits on a redeploy.
“Previously, recovery often involved rolling back a deployment, which took time. With Unleash, it’s much quicker, probably within a few seconds, where we can just roll back a feature.” — Rohan Deshpande, Samsung Ads
The benefit showed up in the metrics the team now tracks. Change failure rate came down, because controlled exposure catches problems before they reach a large audience. Mean time to restore dropped from minutes to seconds. And experimentation scaled up, with Unleash powering consistent user and traffic allocation for experiment assignment across teams.
Integration ran deep rather than bolted on. Samsung Ads treats Unleash as part of the application development lifecycle, not just a release tool, with multiple SDKs across stacks and product teams now using the Unleash API to manage some rollouts directly, without routing every change through engineering.
The team was also clear-eyed about fit. When they evaluated Unleash for ML experiments, they found that workflow had different requirements, with multiple experiment candidates per request, and chose a different pattern for that domain. The takeaway is a healthy one: experimentation is not one size fits all, and Unleash earns its place where controlled rollouts and feature management are the job.
Samsung Ads considers the feature management and rollout side solved. The next frontier is experimentation: using Unleash to deliver more experiments at scale across the organization.
With Unleash, teams can deploy, gradually enable features for a controlled audience, monitor the behavior, and increase rollout as confidence grows. This helps reduce the blast radius if an issue occurs.
Rohan Deshpande
Staff Software Engineer, Samsung Ads
