LaunchDarkly is the feature management platform that software teams use to build better software, faster. Development teams use feature management as a best practice to separate code deployments from feature releases. With LaunchDarkly teams control their entire feature lifecycles from concept to launch to value.
LaunchDarkly is growing quickly in customer count, revenue and employees. We have tripled our run-rate since the beginning of 2017.
We’re already serving over 25b feature flags for our customers every day, and that number is increasing rapidly.
Our customers love the product and our rate of customer churn is exceptionally low.
We’re backed by top venture investors including RedPoint and DFJ.
One of the cool and novel parts of LaunchDarkly is our streaming architecture, which allows us to serve feature flag changes instantly. Think of it like a real-time, in-memory database containing feature flag settings. The closest comparison would be something like Firebase, except Firebase is really more focused on the client-side web and mobile, whereas we do that and the server-side.
We use several technologies to drive our streaming API. The most important is Pushpin / Fanout. These technologies abstract us away from managing these long-lived streaming connections and focus on building simple REST APIs.
We also use Fastly as a CDN. Fastly is perfect for us— we can use VCL to write custom caching rules, and can purge content in milliseconds. If you're caching dynamic content (as opposed to say cat GIFs), or you find yourself needing to purge content programmatically, or you want the flexibility of Varnish in addition to the global network of POPs a CDN can provide, Fastly is the best choice out there. Their support team is also fantastic.
When assembled together, these technologies allow our customers to change their feature flag settings on our dashboard and have their new rollout settings streamed to thousands of servers in a hundred milliseconds or less.
Our customers request over 20 billion feature flags per day, and we use analytics data from these requests to power a lot of the features in our product. A/B testing is an obvious example, but we also do things like determine when a feature flag has stopped being requested, so that you can manage technical debt and clean up old flags.
Our current pipeline involves an HTTP microservice that writes analytics data to DynamoDB. If we need to do any further processing (say, for A/B testing), then we enqueue another job into SQS. Another microservice reads jobs off of the SQS queue and processes them. Right now, we're actively evolving this pipeline. We've found that when we're under heavy load, we need to buffer calls to DynamoDB while we expand capacity instead of trying to process them immediately. Kafka is perfect for this— so we're splitting that HTTP microservice into a smaller HTTP service that simply queues events to Kafka, and another service that processes Kafka queues.
We actually use LaunchDarkly to control this evolution. We have a feature flag that controls whether a request goes through our old analytics pipeline, or the new Kafka-based pipeline we're rolling out. Once the new pipeline is enabled for all customers, we can clean up the code and switch over completely to the Kafka pipeline. This is a use case that surprises a lot of customers— they think of feature flags in terms of controlling user-visible features (release toggles), but they are extremely valuable for other use cases like ops toggles, experiments, and permission management.
As we scaled this service out to handle tens of thousands of request per second, we learned an important lesson about microservice construction. When we first built many of these services, we thought in terms of building a separate service per concern. For example, we’d build a service that would read in analytics events and serve the autocomplete functionality on the site. The web application would make a sub-request to this service when it had an autocomplete request from the site.
We quickly learned that the need for fault tolerance and isolation trumps the conceptual neatness of having a service per concern. With fault tolerance in mind, we sliced our services along a different axis— separating high-throughput analytics writes from the lower-volume read requests coming from the site. This shift dramatically improved the performance of our site, as well as our ability to evolve and scale the huge write load we see on the analytics side.
We’re constantly evolving our service to improve efficiency and scale. Besides the Kafka switchover, we’re looking at using Cassandra for some of the work that DynamoDB is doing right now. We also are keenly interested in Disque as a queuing solution, especially because we’ve had so much positive experience with Redis.
More aspirationally, we might try spiking some of our new services in Rust. I’m a functional programmer at heart, and while I am appreciative of the speed and tooling around Go, it would be nice to regain some of the expressiveness and elegance of a functional language while retaining what we like about Go (the fast compilation times, ease of deployment). If we do try it out, we’ll do so in a cautious manner, and isolate the trial to a new microservice somewhere.
Respect and Integrity - We do our best to create an inclusive space for everyone. At the heart of that is respect and integrity—for our team, our customers, and our community. Teams Do It Better - Great people make even greater teams, and we're proud of the team we've built. We believe in teams, not fiefdoms. Leaders, not tyrants. Individual Growth - LaunchDarkly is a place where everyone can learn and grow. We're dedicated to the professional and personal growth of all our team members. Work Is Not Life - Whether it's spending time with family/friends or having space to pursue hobbies, we make sure work isn't the only thing in our lives.
LaunchDarkly has an unlimited vacation policy (2 week minimum)
All lunches are provided by EatClub and we have a large assortment of healthy snacks and beverages to keep you going throughout the day.
We're in an office in the heart of Downtown Oakland with plenty of natural light and great views of the city.
We provide full medical, dental, and vision coverage for you and your dependents.
We have quarterly outings (movie screenings, baseball games, bowling, bocce ball were some recent ones), and we also have bi-weekly happy hours and spontaneous board game lunches.
We offer pre-tax commuter benefits.
Interested in this company?
Skip straight to final-round interviews by applying through Triplebyte.