StackShareStackShare
Follow on
StackShare

Discover and share technology stacks from companies around the world.

Follow on

© 2025 StackShare. All rights reserved.

Product

  • Stacks
  • Tools
  • Feed

Company

  • About
  • Contact

Legal

  • Privacy Policy
  • Terms of Service
  1. Home
  2. Companies
  3. Lumosity
Lumosity logo

Lumosity

Verified
san franciscowww.lumosity.com
45
Tools
1
Decisions
305
Followers

Tech Stack

Application & Data

26 tools

Bootstrap logo
Bootstrap
Amazon CloudFront logo
Amazon CloudFront
JavaScript logo
JavaScript
Redis logo
Redis
MySQL logo
MySQL
NGINX logo
NGINX
Rails logo
Rails
Ruby logo
Ruby
Amazon S3 logo
Amazon S3
Amazon EC2 logo
Amazon EC2
Objective-C logo
Objective-C
Android SDK logo
Android SDK
Unicorn logo
Unicorn
Amazon EBS logo
Amazon EBS
Amazon VPC logo
Amazon VPC
R Language logo
R Language
Docker logo
Docker
Amazon EMR logo
Amazon EMR
Amazon Redshift logo
Amazon Redshift
Kubernetes logo
Kubernetes
AngularJS logo
AngularJS
Java logo
Java
Scala logo
Scala
Hadoop logo
Hadoop
Amazon EC2 Container Service logo
Amazon EC2 Container Service
Amazon Aurora logo
Amazon Aurora

Utilities

7 tools

Google Analytics logo
Google Analytics
Twilio SendGrid logo
Twilio SendGrid
Slack logo
Slack
Amazon SNS logo
Amazon SNS
Kafka logo
Kafka
Zookeeper logo
Zookeeper
Chartio logo
Chartio

DevOps

10 tools

GitHub logo
GitHub
Jenkins logo
Jenkins
Travis CI logo
Travis CI
Chef logo
Chef
Rollbar logo
Rollbar
Nagios logo
Nagios
Jira logo
Jira
Git logo
Git
Code Climate logo
Code Climate
Fluentd logo
Fluentd

Business Tools

2 tools

jQuery logo
jQuery
D3.js logo
D3.js

Team Members

Jay OConnor
Jay OConnorPlatform and DevOps Manager
Marc Bollinger
Marc BollingerInfra & Data Eng Manager

Engineering Blog

Stack Decisions

Marc Bollinger
Marc Bollinger

Dec 3, 2018

Lumosity is home to the world's largest cognitive training database, a responsibility we take seriously. For most of the company's history, our analysis of user behavior and training data has been powered by an event stream--first a simple Node.js pub/sub app, then a heavyweight Ruby app with stronger durability. Both supported decent throughput and latency, but they lacked some major features supported by existing open-source alternatives: replaying existing messages (also lacking in most message queue-based solutions), scaling out many different readers for the same stream, the ability to leverage existing solutions for reading and writing, and possibly most importantly: the ability to hire someone externally who already had expertise.

We ultimately migrated to Kafka in early- to mid-2016, citing both industry trends in companies we'd talked to with similar durability and throughput needs, the extremely strong documentation and community. We pored over Kyle Kingsbury's Jepsen post (https://aphyr.com/posts/293-jepsen-Kafka), as well as Jay Kreps' follow-up (http://blog.empathybox.com/post/62279088548/a-few-notes-on-kafka-and-jepsen), talked at length with Confluent folks and community members, and still wound up running parallel systems for quite a long time, but ultimately, we've been very, very happy. Understanding the internals and proper levers takes some commitment, but it's taken very little maintenance once configured. Since then, the Confluent Platform community has grown and grown; we've gone from doing most development using custom Scala consumers and producers to being 60/40 Kafka Streams/Connects.

We originally looked into Storm / Heron , and we'd moved on from Redis pub/sub. Heron looks great, but we already had a programming model across services that was more akin to consuming a message consumers than required a topology of bolts, etc. Heron also had just come out while we were starting to migrate things, and the community momentum and direction of Kafka felt more substantial than the older Storm. If we were to start the process over again today, we might check out Pulsar , although the ecosystem is much younger.

To find out more, read our 2017 engineering blog post about the migration!

1.89M views1.89M
Comments