At Seasoned, we’re a startup focused on taking a giant bite out of the high growth, high turnover and low satisfaction workers face in the food service industry.

An integral part of our vision is to build a vibrant and useful network of food service industry workers.  Not only are we building a platform that provides greater transparency, access, and ease for people who are on the job hunt right now – we want our platform to be a place where folks can connect with others, expand their professional network and grow their careers.

For our data science team, turning our vision into reality hinged on two key tasks: (1) Connect the right job opportunities to the right candidates, and (2) connect people in a logical, intuitive and delightful way.  We knew we wanted to use graph theory and recommender systems, but we needed something that could help us easily explore and mine the data we have, handle quick iterations on testing, and help us connect the success to experiments.

In thinking about data storage and management needs, we wanted to easily manage millions of nodes and complex, ever-evolving sets of relationships between them; support business intelligence analysis and deeper data science research needs; while simultaneously honoring performance and scalability considerations. The wrong choice would leave everything we’re building vulnerable and risk slowing us down or even, worst-case, force us to re-do our graph data foundation.

While there are several good options out there, we determined quickly that Neo4J was the best choice: It is the industry leader, has a vibrant community, and met our biggest technology requirements for a GraphDB.

Since making that decision, we’ve successfully implemented Neo4J to our technology stack and stood-up a microservice in front of Neo. This service runs as a Neo4J embedded Java application (another nice feature of Neo). In addition, we have built data flows to and from Neo to support our business intelligence and data science needs, and everything is High Availability, running in a clustered environment.

What this all boils down to is this: We can now quickly access our graph data to support analysis and research while seamlessly making production updates with a simple hand-off process to Engineering. In later editions of our story, we will be exploring how we deployed our neo4j cluster in our production VPC, how our neo4j evolved from conception to actual implementation, and ways we are testing and iterating our production versions. We’re excited with the progress thus far, and we’re only just scratching the surface of what we can accomplish. Neo is giving us exactly what we had hoped for and we feel poised to grow and learn as our data gets richer.  Onward and upward!!!

One Comment

Leave a Reply