Live data from Hacker News

How LaunchDarkly Serves Over 4B Feature Flags Daily

stackshare.io

1–10 of 20 posts

Re: How LaunchDarkly Serves Over 4B Feature Flags Daily

#2
MongoDB -- as our core application data store. It's popular to make fun of Mongo these days, but we've found it to be a great database technology as long as you don't store too many things in it. Anything you can count on your fingers and toes should be fine.

I suspect this is a joke, but I'm still confused? If 4B things happen every day, how is that finger-toe countable? Does this mean that relatively slowly-changing things like "customer name" are stored in mongo while events etc. are stored elsewhere?

Re: How LaunchDarkly Serves Over 4B Feature Flags Daily

#4

MongoDB -- as our core application data store. It's popular to make fun of Mongo these days, but we've found it to be a great database technology as long as you don't store too many things in it. Anything you can count on your fingers and toes should be fine. I suspect this is a joke, but I'm still confused? If 4B things happen every day, how is that finger-toe countable? Does this mean that relatively slowly-changin…

I was being cheeky :)

Events are stored in DynamoDB. We use mongo for "core" data like accounts, feature flags, etc, but none of the high throughput stuff touches MongoDB.

Re: How LaunchDarkly Serves Over 4B Feature Flags Daily

#7
post #4

MongoDB -- as our core application data store. It's popular to make fun of Mongo these days, but we've found it to be a great database technology as long as you don't store too many things in it. Anything you can count on your fingers and toes should be fine. I suspect this is a joke, but I'm still confused? If 4B things happen every day, how is that finger-toe countable? Does this mean that relatively slowly-changin…

I was being cheeky :) Events are stored in DynamoDB. We use mongo for "core" data like accounts, feature flags, etc, but none of the high throughput stuff touches MongoDB.

> Events are stored in DynamoDB. We use mongo for "core" data like accounts, feature flags, etc, but none of the high throughput stuff touches MongoDB.

Curious, why the choice of MongoDB for anything? In my mind "core" data tends to be very structured and require true transactional updates, both of which are cornerstones of a relational database (cough Postgres). Sure it's possible to use MongoDB, but what was the driver for it?

Re: How LaunchDarkly Serves Over 4B Feature Flags Daily

#8
post #7
post #4

Earlier quoted context omitted.

I was being cheeky :) Events are stored in DynamoDB. We use mongo for "core" data like accounts, feature flags, etc, but none of the high throughput stuff touches MongoDB.

> Events are stored in DynamoDB. We use mongo for "core" data like accounts, feature flags, etc, but none of the high throughput stuff touches MongoDB. Curious, why the choice of MongoDB for anything? In my mind "core" data tends to be very structured and require true transactional updates, both of which are cornerstones of a relational database ( cough Postgres ). Sure it's possible to use MongoDB, but what was the…

We had a lot of operational experience with Mongo from our previous jobs at Atlassian, and started out storing almost everything in Mongo. As we scaled out, we migrated all of our high volume data into other stores-- analytics into DynamoDB, searchable data into ElasticSearch, etc.

The last remaining piece is our core data, and there's no strong push to move it out of Mongo.

Post reply on HN