Share your story at MongoDB.live 2021
MongoDB Applied
Customer stories, use cases and experience
Built with MongoDB: Spectro Cloud
Recently named one of the hottest Kubernetes startups , Spectro Cloud has been making waves across the tech ecosystem. An enterprise cloud-native infrastructure founded by three startup veterans, Spectro Cloud makes Kubernetes manageable at scale for enterprises that need manageability and flexibility. Spectro Cloud’s cluster profiles automate cluster deployment and maintenance across the enterprise and help operations prioritize the needs of the applications teams and simplify infrastructure administration. The company has raised $7.5 million in seed funding and has 36 team members. In this edition of #BuiltWithMongoDB, we talk to CTO/Co-founder Saad Malik and Vice President of Product Tina Nolte about Spectro Cloud’s deeply technical team and why they #BuiltWithMongoDB. Siya Raj Purohit: What makes you want to work at Spectro Cloud? Tina Nolte: Most of the team comes from Cisco, where the founders previously worked, so we already had good rapport and were truly friends. We believe that culture is something you build from Day 1, and once it exists, it’s hard to change. For that reason, we have a strict no-jerks policy. How that plays out is that we provide a lot of autonomy to the team and help support goals that individuals have. For example, we encourage everyone on the team to write blog content about things they are interested in to share their knowledge and build their personal brands. It’s something that our engineering managers even nudge junior engineers about: “So you haven’t shared any wisdom with the world recently — why don’t you write a post?” If you—as a developer—experience some kind of issue, or it took you time to understand something, it’s likely that someone else on the planet has experienced that issue too. So we encourage our engineers to help them out, and it’s good for our engineers to have an external presence, too. See Spectro Cloud’s post: Kustomize your way to MongoDB ReplicaSet Finally, we talk about Spectro Cloud as a family. We’re pretty confident that other people have our backs whether it’s personally or professionally, and that kind of connectivity is pretty special. SRP: How did you decide to start using MongoDB? Saad Malik: Our application is not very data heavy in terms of transactions or relations; it’s very document based. Although we are running a SaaS platform, we didn’t want to be in the business of doing backups, managing policy, and storing configurations. We wanted to use a platform that managed these things for us. So we were looking at Amazon’s DocumentDB or MongoDB Atlas. We realized we would have to use an on-premises version of our platform, so obviously if we were to be running an on-premises version of MongoDB, it would make sense to use Atlas. Our team also had experience with MongoDB so it was a clear choice. And it’s been fantastic — we have been very happy with the performance, and so far, it’s been scaling very well for us. SRP: What has it been like to scale with MongoDB? SM: It’s been fantastic — we haven’t had any outages with Atlas. We obviously have our notifications configured so if there are any outages or things going wrong with the MongoDB clusters, we can catch when one of our clusters is misbehaving. That visibility and getting the monitoring upfront is very helpful to us, because we’re able to figure out which of our application issues is causing the problem. When we were getting started, we had a technical advisor from MongoDB provide us with a one-day seminar on best practices for utilizing the platform and how to optimize queries. From then on, the online documentation has been sufficient for us to problem solve and scale. SRP: What does the database infrastructure look like today? SM: On the database side, we have three different environments: dev integration, stage, and production. All three of them run an Atlas version from a database that is completely separate. The stack that sits on top of it is Kubernetes application, all using Golang, DB drivers for MongoDB, and accessing the application on there. SRP: What advice do you have for developers who aspire to someday become CTO? SM: The number one thing I look for is someone who is very curious. When I was an early-career engineer, my mentors would tell me to always be very curious and focused in terms of what you’re doing. Understand how things are working, not just at the library level, but keep on digging down until you understand not just how, but why something works a certain way. If you understand the nuances, you’ll be able to identify true game-changing opportunities. Building something cool with MongoDB? Check out our developer resources , and let us know if you want your startup to be featured in our #BuiltWithMongoDB series.
Flowhub Relies on MongoDB to Meet Changing Regulations and Scale Its Business
The legal landscape for cannabis in the United States is in constant flux. Each year, new states and other jurisdictions legalize or decriminalize it, and the regulations governing how it can be sold and used change even more frequently. For companies in the industry, this affects not only how they do business, but also how they manage their data. Responding to regulatory changes requires speedy updates to software and a database that makes it easy to change the structure of your data as needed – and that’s not to mention the scaling needs of an industry that’s growing incredibly rapidly. Flowhub makes software for the cannabis industry, and the company is leaping these hurdles every day. I recently spoke with Brad Beeler , Lead Architect at Flowhub, about the company, the challenges of working in an industry with complex regulations, and why Flowhub chose MongoDB to power its business. We also discussed how consulting from MongoDB not only improved performance but also saved the company money, generating a return on investment in less than a month. Eric Holzhauer: First, can you tell us a bit about your company? Brad Beeler: Flowhub provides essential technology for cannabis dispensaries. Founded in 2015, Flowhub pioneered the first Metrc API integration to help dispensaries stay compliant. Today, over 1,000 dispensaries trust Flowhub's point of sale, inventory management, business intelligence, and mobile solutions to process $3B+ cannabis sales annually. Flowhub in use in a dispensary EH: How is Flowhub using MongoDB? BB: Essentially all of our applications – point of sale, inventory management, and more – are built on MongoDB, and we’ve been using MongoDB Atlas from the beginning. When I joined two and a half years ago, our main production cluster was on an M40 cluster tier, and we’ve now scaled up to an M80. The business has expanded a lot, both by onboarding new clients with more locations and by increasing sales in our client base. We’re now at $3 billion of customer transactions a year. As we went through that growth, we started by making optimizations at the database level prior to throwing more resources at it, and then went on to scale the cluster. One great thing about Atlas is that it gave us the metrics we needed to understand our growth. After we’d made some optimizations, we could look at CPU and memory utilization, check that there wasn’t a way to further improve query execution with indexes, and then know it was time to scale. It’s really important for usability that we keep latency low and that the application UI is responsive, and scaling in Atlas helps us ensure that performance. We also deploy an extra analytics node in Atlas, which is where we run queries for reporting. Most of our application data access is relatively straightforward CRUD, but we run aggregation pipelines to create reports: day-over-day sales, running financials, and so forth. Those reports are extra intensive at month-end or year-end, when our customers are looking back at the prior period to understand their business trends. It’s very useful to be able to isolate that workload from our core application queries. I’ll also say that MongoDB Compass has been an amazing tool for creating aggregation pipelines. EH: Can you tell us some more about what makes your industry unique, and why MongoDB is a good fit? BB: The regulatory landscape is a major factor. In the U.S., there’s a patchwork of regulation, and it continues to evolve – you may have seen that several new states legalized cannabis in the 2020 election cycle. States are still exploring how they want to regulate this industry, and as they discover what works and what doesn’t, they change the regulations fairly frequently. We have to adapt to those changing variables, and MongoDB facilitates that. We can change the application layer to account for new regulations, and there’s minimal maintenance to change the database layer to match. That makes our development cycles faster and speeds up our time to market. MongoDB’s flexibility is great for moving quickly to meet new data requirements. As a few concrete examples: The state of Oregon wanted to make sure that consumers knew exactly how much cannabis they were purchasing, regardless of format. Since some dispensaries sell prerolled products, they need to record the weight of the paper associated with those products. So now that’s a new data point we have to collect. We updated the application UI to add a form field where the dispensary can input the paper weight, and that data flows right into the database. Dispensaries are also issuing not only purchase receipts, but exit labels like what you’d find on a prescription from a pharmacy. And depending on the state, that exit label might include potency level, percentage of cannabinoids, what batch and package the cannabis came from, and so on. All of that is data we need to be storing, and potentially calculating or reformatting according to specific state requirements. Everything in our industry is tracked from seed to sale. Plants get barcodes very early on, and that identity is tracked all the way through different growth cycles and into packaging. So if there’s a recall, for example, it’s possible to identify all of the products from a specific plant, or plants from a certain origin. Tracking that data and integrating with systems up the supply chain is critical for us. That data is all tracked in a regulatory system. We integrate with Metrc , which is the largest cannabis tracking system in the country. So our systems feed back into Metrc, and we automate the process of reporting all the required information. That’s much easier than a manual alternative – for example, uploading spreadsheets to Metrc, which dispensaries would otherwise need to do. We also pull information down from Metrc. When a store receives a shipment, it will import the package records into our system, and we’ll store them as inventory and get the relevant information from the Metrc API. Flowhub user interface EH: What impact has MongoDB had on your business? BB: MongoDB definitely has improved our time to market in a couple of ways. I mentioned the differences of regulation and data requirements across states; MongoDB’s flexibility makes it easier to launch into a new state and collect the right data or make required calculations based on data. We also improve time to market because of developer productivity. Since we’re a JavaScript shop, JSON is second nature to our developers, and MongoDB’s document structure is very easy to understand and work with. EH: What version of MongoDB are you using? BB: We started out on 3.4, and have since upgraded to MongoDB 4.0. We’re preparing to upgrade to 4.2 to take advantage of some of the additional features in the database and in MongoDB Cloud. One thing we’re excited about is Atlas Search : by running a true search engine close to our data, we think we can get some pretty big performance improvements. Most of our infrastructure is built on Node.js, and we’re using the Node.js driver . A great thing about MongoDB’s replication and the driver is that if there’s a failover and a new primary is elected, the driver keeps chugging, staying connected to the replica sets and retrying reads and writes if needed. That’s prevented any downtime or connectivity issues for us. EH: How are you securing MongoDB? BB: Security is very important to us, and we rely on Atlas’s security controls to protect data. We’ve set up access controls so that our developers can work easily in the development environment, but there are only a few people who can access data in the production environment. IP access lists let us control who and what can access the database, including a few third-party applications that are integrated into Flowhub. We’re looking into implementing VPC Peering for our application connections, which currently go through the IP access list. We’re also interested in Client-Side Field-Level Encryption . We already limit the amount of personally identifiable information (PII) we collect and store, and we’re very careful about securing the PII we do need to store. Client-Side Field-Level Encryption would let us encrypt that at the client level, before it ever reaches the database. EH: You're running on Atlas, so what underlying cloud provider do your use? BB: We’re running everything on Google Cloud. We use Atlas on Google Cloud infrastructure, and our app servers are running in Google Kubernetes Engine. We also use several other Google services. We rely pretty heavily on Google Cloud Pub/Sub as a messaging backbone for an event-driven architecture. Our core applications initially were built with a fairly monolithic architecture, because it was the easiest approach to get going quickly. As we’ve grown, we’re moving more toward microservices. We’ve connected Pub/Sub to MongoDB Atlas, and we’re turning data operations into published events. Microservices can then subscribe to event topics and use the events to take action and maintain or audit local data stores. Our data science team uses Google BigQuery as the backend to most of our own analytics tooling. For most uses, we migrate data from MongoDB Atlas to BigQuery via in-house ETL processes, but for more real-time needs we’re using Google Dataflow to connect to MongoDB’s oplog and stream data into BigQuery. EH: As you grow your business and scale your MongoDB usage, what's been the most important resource for you? BB: MongoDB’s Flex Consulting has been great for optimizing performance and scaling efficiently. Flowhub has been around for a number of years, and as we’ve grown, our database has grown and evolved. Some of the schema, query, and index decisions that we had made years ago weren’t optimized for what we’re doing now, but we hadn’t revisited them comprehensively. Especially when we were scaling our cluster, we knew that we could make more improvements. Our MongoDB Consulting Engineer investigated our data structure and how we were accessing data, performance, what indexes we had, and so on. We even got into the internals of the WiredTiger storage engine and what optimizations we could make there. We learned a ton about MongoDB, and the Consulting Engineer also introduced us to some tools so we could diagnose performance issues ourselves. Based on our Consulting Engineer’s recommendations, we changed the structure of how we stored some data and reworked certain queries to improve performance. We also cleaned up a bunch of unnecessary indexes. We had created a number of indexes over the years for different query patterns, and our Consulting Engineer was able to identify which ones could be removed wholesale, and which indexes could be replaced with a single new one to cover different query patterns. We made some optimizations in Atlas as well, moving to a Low CPU instance based on the shape of our workload and changing to a more efficient backup option. With the optimizations recommended in our consulting engagement, we were able to reduce our spend by more than 35%. MongoDB consulting paid for itself in less than a month, which was incredible. I had to develop a business case internally for investing in consulting, and this level of savings made it an easy sell. The knowledge we picked up during our consulting engagement was invaluable. That’s something we’ll carry forward and that will continue to provide benefits. We’re much better at our indexing strategy, for example. Say you’re introducing a new type of query and thinking about adding an index: now we know what questions to ask. How often is this going to be run? Could you change the query to use an existing index, or change an existing index to cover this query? If we decide we need a new index, should we deprecate an old one? With the optimizations recommended in our consulting engagement, we were able to reduce our spend by more than 35%. MongoDB consulting paid for itself in less than a month, which was incredible. Brad Beeler, Lead Architect, Flowhub EH: What advice would you give to someone who's considering MongoDB for their next project? BB: Take the time upfront to understand your data and how it’s going to be used. That’ll give you a good head start for structuring the data in MongoDB, designing queries, and implementing indexes. Obviously, Flex Consulting was very helpful for us on this front, so give that a look.
Built with MongoDB: Coursedog
Nicholas Diao and Justin Wenig had just joined the undergraduate program at Columbia University and were excited to take their first computer science class. They registered and, to their delight, were accepted into the course. When they showed up to the first class, however, they were greeted with distressing news: the class was double-booked. As they quickly discovered, their situation was hardly unique. Universities, such as their own, often lack the software to manage the complexities of class scheduling. They decided to fix that. What started as an undergraduate project to solve a local problem turned into Coursedog , a Y Combinator backed curriculum success platform for higher education. Coursedog works with more than 70 universities to modernize the way they propose, schedule, and publish their classes to students. Coursedog has raised $4.2M in funding and been building with MongoDB since Day 1. Both founders were recently named to Forbes 30 under 30. In this edition of #BuiltWithMongoDB, we talk to Nicholas about being a student founder, building prototypes to find product-market fit, and growing with the MongoDB platform. Siya Raj Purohit: Coursedog started while you were still in college. Let’s talk about how you came across the problem your platform is built to address. Nicholas Diao: My co-founder Justin and I both wanted to be in a specific CS class. On the first day of class, we had our textbooks, our coffee, and our snacks, and were ready to go - and then we realized the professor wasn’t there. It turns out the professor had been double-booked. As aspiring CS majors, we thought “how can this be a problem of the 21st century?!” We assumed there was some automated system that ensured smooth scheduling for university classes. But it turned out that what we thought would be an automated system was a couple of overworked administrators with Microsoft Excel spreadsheets in a dark back room where they had to build the schedule themselves. And, of course, that process is error-prone and not the best use of time for university administrators. Justin and I spoke to around 400 to 500 university administrators to better understand the scheduling process, which is far more complex than it appears and has an immense impact on students and their ability to get the courses they need to learn and graduate. We realized this was a problem that was mostly ignored. Columbia Law School joined us as a design partner, and we started building a simple prototype to address this problem and make the system better for all universities. SRP: What was your initial prototype like? ND: We used simple HTML, CSS, JavaScript, and Node.JS server with a MongoDB database. Part of the reason we chose MongoDB is its ability to be really flexible, because we were learning and iterating day after day. A few months later, we ended up signing our first official school contract at Brigham Young University based on good references from Columbia Law School. In the winter of 2019, we entered Y Combinator. After we graduated from YC, we raised $4M in Series A funding, and now we’re working with more than 70 institutions and have released three additional products focused on curriculum management, event management, and catalog management. We have a team of more than 40 people across three countries. SRP: What does your tech stack consist of? ND: It's the MEVN stack: MongoDB, Express.js, Vue.js, and Node.js. We use AWS for architecture. SRP: When you started building Coursedog, you were still a CS student. How did you decide to choose MongoDB? ND: There are a couple of reasons why we started building with MongoDB. Early on, we wanted to quickly build demos that our customers could provide immediate feedback on. We knew we were tackling a complex problem and we didn’t know what our ultimate data structure would be, so we wanted a database that could be as flexible and iterative as possible and that ended up being a NoSQL database that was cloud-hosted. MongoDB came to the top of that list. It was a great decision, because we made many modifications to our data model and MongoDB managed the complexity of our solution while being easier than any other database. What got our team to really fall in love with MongoDB was the power of what we were able to do with it . There are relationships between different data objects (for example, for an economics class, managing all the components you need to know: room size, class size, department, and so on). We’re able to do very powerful joins in the SQL database and complex filters. We can build out everything we need in an iterative fashion, and MongoDB has all the functions to enable us to build more complicated features over time. We once spoke with a MongoDB technical advisor too: aggregation pipelines were new to us, and our conversation gave us great footing for getting started. From there on, the MongoDB documentation has been detailed enough to help us navigate scaling challenges. SRP: Now you’re used by more than 70 universities. How has your experience been scaling up with MongoDB? ND: We’ve found it really easy to scale because of the seamlessness and flexibility of the product and its easy communication. We have a clear sense of how much data we’re using and what the performance metrics are, and we get timely notifications. We really appreciate that if you hit 80% of a specific metric, MongoDB will send you a notification. This has been hugely helpful to our DevOps and infrastructure folks for monitoring. We’ve actually taken some cues from that: if you have 80% of a room booked, we send a notification to our users. As we’ve scaled and worked with an increasing amount of data (typically there are between 150 and 200 data types for each school), we have found that MongoDB has the flexibility and customizations we required. This is sometimes a contrast to AWS, our architectural tool. Doing the same things in AWS is much harder. For example, to change notifications (or even set them up), you have to read AWS’s incomprehensible online documentation, and then there are about 30 different places you can go to make that change on the site. In contrast, MongoDB makes it so easy to manage the back-end so we can focus on building the business. SRP: What advice would you have for college students who aspire to build their own company and move into the CTO role for that company? ND: The most important skill to pick up during college is collaboration. The way schools evaluate students is all content-focused (test, papers, problem sets) but what really matters in your career is your ability to collaborate with other people. I wouldn’t have gotten anywhere if Justin and I were not able to build a strong partnership and work with other smart, hard-working people to get Coursedog off the ground. For college students, I would say that in the long run, it doesn’t matter what grade you get on that problem set or lab; it matters if you’re able to work well with the people around you. My second piece of advice is when building solutions, start small, start local, and start trying to solve problems for the people around you - as we did with Coursedog. The best companies come from solving personal problems and then building it out from there. Building something cool with MongoDB? Check out our developer resources , and let us know if you want your startup to be featured in our #BuiltWithMongoDB series.
Vietnam's #1 Entertainment Network Accelerates International Growth with MongoDB Atlas and Google Cloud
With a high youth demographic, and a population whose first phone was a smartphone, Vietnam has unique conditions that are accelerating its pace of digital transformation throughout the country as it races to keep pace with neighboring countries. Digital entertainment is one of Vietnam's boom industries. POPS , founded in Vietnam in 2007, has grown to become the leading digital entertainment company in Southeast Asia. It is the #1 network in Vietnam, providing 830+ channels and generating 4.4 billion views per month. The trick, according to POPS’ Chief Technology Officer, Martin Papy, is “hyper-local content for every demographic.” POPS scours audience data to inform new content formats, programming, promotions and deals with local and international content creators. Quickly developing and delivering new applications is central to POPS' go-to-market strategy. To achieve this, POPS has taken the strategic decision to run its suite of apps on MongoDB Atlas and Google Cloud. The main POPS App is an all-in-one content platform and is available on smartphones, smart TVs, website, mobile and tablets. To compliment that app, POPS also recently launched POPS Kids . As the name suggests, Kids is for under-12s and provides a wide range of local and international edutainment and entertainment content. “Deciding on the MongoDB database platform was a simple decision,” Martin says. “We could run it on-premises, it provides a straightforward architecture, and it comes with the full support for restful APIs out of the box. It made it easy for a team of two engineers to build our POPS Kids application very quickly.” This setup worked fine when POPS was Vietnam-based only, with MongoDB running on POPS’ on-premises infrastructure, but was problematic when looking at spiky growth in international markets. “To scale, it was obvious we needed a cloud-based infrastructure,” Martin explained. The advantage of using MongoDB Atlas is that it allows us to expand in the region without significant time investment from our team. Martin Papy, Chief Technology Officer, POPS To solve that problem, POPS turned to MongoDB Atlas , MongoDB's fully managed cloud service, and chose Google Cloud as its cloud provider. Since POPS was already using YouTube and exporting its data from YouTube to Google BigQuery, moving its on-premises infrastructure to Google Cloud was the logical next step. Along with allowing for scale, using MongoDB Atlas simplified the task of database and backup management for the POPS team. Within two years the POPS Kids app has gone from nothing to signing 1.5 million users and generated over 32 million views. This is not simply a story of rapid growth. POPS has also reimagined its developer culture to retain agility as it adds capacity. POPS has reconfigured its monolithic architecture into smaller, more nimble microservices. Developers can now reuse existing components, saving time and freeing them to focus on service improvements. Martin has a team of 50 engineers working full-time on the platform. In just a few clicks, the team can configure, restore or query any point in time in the database's history. It ensures both disaster recovery and the ability to quickly spin up environments for testing new features. “The advantage of building our application using MongoDB Atlas is that it allows us to expand in the region without significant time investment from our team. We can take advantage of the multi-region replication to maintain our level of service. That is incredibly valuable to us," said Martin. This flexibility and capability meant that MongoDB could match POPS’ fast growth curve, from ambitious startup to regional enterprise. For Martin, rapid expansion should not be at the expense of security and control. “MongoDB gives built-in control over all our data. It gives us enterprise-grade features to integrate with our own security protocols and compliance standards. We can deploy a dedicated cluster in a unique virtual private network with its own firewall," he added. MongoDB Atlas now provides all of POPS's apps with a fully managed service on Google’s globally scalable and reliable infrastructure. The broader business is thriving. POPS now provides music, esports, news and game show content to over 212 million subscribers. Today, POPS is present in Vietnam, Thailand and Indonesia, and plans to add new markets in 2021. POPS Kids has become the most beloved and well-known kids’ brand in Southeast Asia. Watch the full video from POPS' presentation at MongoDB.live here .
Showingly Transforms Real Estate with MongoDB Atlas and MongoDB Realm
Buying or selling a house is difficult. There are more steps than you could imagine, and each one feels harder than it should be. The improvements that technology has made in the past decades seem to have passed the industry by. Showingly is trying to make the process less difficult, starting by making it easier to see houses you might want to buy. Buyers can browse listings and book showings with no fuss. Sellers and their agents can make listings available on the app, making it easier for buyers to find them. Agents and other real estate professionals can simplify their workflows. Showingly built its full stack on MongoDB, using MongoDB Atlas and MongoDB Realm . I caught up with Andrew Coca, Co-Founder and President, to learn more. Tell us a little bit about your company. Showingly is a real estate platform for buyers, sellers, and professionals. Of course, it does everything you would expect: sellers can have their house listed on the platform, buyers can browse listings and see all of the important details, agents can manage their listings, and so on. What sets Showingly apart is that consumers can actually drive the showing process, instead of merely searching for homes. On most real estate platforms, if you find a house you’re interested in, you might see a list of times and dates to schedule an appointment, but you’re not actually booking a showing. Instead, the platform sells that to an agent as a lead, and the agent has to follow up with you – they may or may not be able to show you the house at that time. Showingly is an actual showing platform: when you book a showing, we’re really scheduling it for you in our backend. Until now, the home showing process has been prioritizing agent convenience instead of consumer convenience. Now, for the first time, consumers can have the transparency of directly booking the showings they want. We also have features built for agents and other professionals. For example, agents are able to delegate showings. If you’re too busy, you can find another agent to show one of your listings; on the other side of the coin, if you have spare time, you can turn that into money by picking up delegated showings. We’ve been building Showingly for two years, and we launched publicly five months ago. We’re currently live in Alaska, Arizona, Colorado, Hawaii, Massachusetts, South Carolina, Tennessee, and Utah. We continue to integrate with more multiple listing services (MLSs) to launch into new markets. I have to ask: What has your experience been launching a real estate application during a global pandemic? Early on, it made raising funding a little harder, but we were able to find investors who wanted to invest during COVID. Surprisingly, it then made hiring easier: people who had lost their internships or jobs came to work for us. We grew from a couple engineers to a dozen, and we’ve probably built as much in the last two months as we did in the year before. It hasn’t had an enormous effect at a business level. As you might know, real estate markets have reacted in very different ways to COVID. In the Northeast, the market is cautious, but here in Colorado, it’s booming. What was the genesis of Showingly? We wanted to start Showingly after learning the ins and outs of the industry through real estate sales. I’ve been an agent, I’ve managed a team of agents, and I’ve experienced a lot of parts of the process. Real estate is such an archaic industry. Technology has done so much in the last 10 or 20 years, and the real estate industry hasn’t materially improved. Sure, there have been some new applications, but they don’t fundamentally change the process – they just put the old process into a pretty website. We saw a big opportunity to actually transform the industry. How is Showingly using MongoDB? Showingly is built fully on MongoDB. We’re storing all of our data in MongoDB Atlas, running on AWS. We have one main production cluster, plus a few dev and test clusters. Our application backend is built entirely on MongoDB Realm, using Realm Functions . It’s really nice to have it all in one place. We use functions for data movement, like retrieving listings from an MLS, as well as application functionality. When you take any action in the app – displaying listings, displaying showings, creating a new showing, updating a showing, and so on – that’s calling a Realm function to access the data in MongoDB Atlas. For frontend, we have a cross-platform mobile app built with React Native, as well as a web client for agents and other professionals. It’s easy to connect to Realm and Atlas from those different clients. What made you decide to use MongoDB Atlas and Realm’s application development services? We went to MongoDB World last year, and learned about the document model, MongoDB Atlas, MongoDB Realm, and all of your other products. We knew then that it was the right way to build a simple but powerful architecture. MongoDB has made it easy to get started, but it will also scale with our business: we could go nationwide or worldwide, and MongoDB makes that easy. There’s no reason we would ever need to change our backend. As I mentioned, my background is in real estate, not technology. But over the past couple of years, I’ve gotten quite good at working with MongoDB Realm and MongoDB Atlas. The simplicity of JavaScript on the frontend and MongoDB on the backend makes it an easy stack to work with. And getting expert help from a consulting engineer quickly taught us the best practices for developing with MongoDB. Working with MongoDB let us develop a great application quickly. And how would you describe the benefit of MongoDB to your business? Time to market is certainly part of it, as I mentioned. But I wouldn’t have picked MongoDB just for that. Building for the long term is more important to me than time to market. I wouldn’t take on technical debt up front just to be able to move more quickly. I want to build a structure that lasts, and I’m confident that what we’re building with MongoDB Realm and MongoDB Atlas is just that. You mentioned that the ability to handle scaling in the future was key for you. What are your plans for scale? We actually use auto-scaling in Atlas, so our production cluster automatically scales up and down depending on workload. Right now, it’s usually either an M10 or an M20, fluctuating between them as needed. If and when the workload of our application increases beyond that level, Atlas will continue to scale up to match. It’s so easy to set up auto-scaling, so why do it ourselves? And we know that if we need to move to a multi-region cluster or global cluster, that’s very easy to do. And of course, MongoDB Realm is serverless and we don’t need to worry about scale on that side at all. We just define functions, and they run when needed at any scale. You said you worked with a MongoDB consulting engineer. Can you describe that process? Flex Consulting not only gave us the expert help we needed, but pulled us along the path to being expert MongoDB users ourselves. We’ve had several Flex Consulting engagements in the Design & Develop and Optimize tracks. Flex Consulting has been the key to making the best use of MongoDB Atlas and MongoDB Realm for our application. We actually covered a number of different points in our consulting engagements. First and foremost was getting the schema design right. For example, our consulting engineer helped us model the data structure of listings and showings (e.g., embedding vs. linking information), and how to represent data in a way that matches how the application uses it. Getting that design right the first time definitely helped avoid more work down the road. Advice from the MongoDB engineer also helped us control data quality when multiple people and processes can update records. We fetch listings from MLSs, and if all we had to do was present listings, it would be simple. But of course we’re also dealing with showings tied to listings, we’re enriching those records with other fields for our specific use, and there are cases where an agent might be modifying some of that extra data. So when we refresh listings from the MLS or make updates from the application, we need to make sure that those updates aren’t clobbering other data. Our consulting engineer helped us design Realm functions that would have the correct upsert behavior in all cases. These consulting engagements were almost like school for us. We spent time with our consulting engineer understanding the technology and making the right design decisions, which was super valuable. Flex Consulting not only gave us the expert help we needed, but pulled us along the path to being expert MongoDB users ourselves. What’s next for Showingly? In the short term, it’s about growing use in the markets where Showingly is live, and launching into new markets. On the product side, we’re adding some social elements so that agents can see what their peers are up to. We’re also very eager to do more analysis of our data, integrating machine learning to do things such as improving pricing for some of our agent features. What advice would you give to someone considering MongoDB for their next project? First, take advantage of consulting. MongoDB’s consulting is the best way to build your project not only quickly, but correctly for the long term. Second, you’ll get the biggest benefit from utilizing the whole stack of Realm and Atlas together. There’s an enormous amount of convenience from having everything in one place. In the long term, we want Showingly to be the real estate platform. To date, real estate hasn’t had a good platform that facilitates the process. If you’ve ever bought or sold a home, you know how convoluted it is. You should be able to do everything in a single platform: finding potential homes, getting pre-approvals, scheduling and going on showings, writing an offer, signing contracts and other documents, even closing and getting insurance. We want Showingly to be that platform, to turn a 30-day process into a 3-day process.
Built with MongoDB: Price.com
A few years ago, RJ Jain moved to San Francisco and wanted to buy a couch for his new apartment. Shortly after making an online purchase for a new couch, he found a listing for the exact same couch, previously owned, on another site for half the retail price. That's when RJ had his “ah-ha” moment. “If I bought this used item, I would have saved so much money. Plus, buying the used couch would have been responsible shopping—much better for the environment, he explains. And with that, the idea of Price.com was born. Price.com is building a platform that helps users save time and maximize savings when purchasing products online. On the platform, users can compare prices across product conditions (e.g. new, used, refurbished, rental) and leverage coupons, price alerts, and a cash-back rewards program. Price.com has grown quickly - the platform showcases over one billion product listings across 2,000 retail partnerships, and is experiencing a 30% user growth month-over-month. The company has raised funding from Founders Fund; Social Capital; and angels including former execs at Twitter, Priceline, Microsoft, and Pinterest. For this episode of #BuiltWithMongoDB, we spoke with Vasco Morais , Director of Engineering at Price.com about the company’s tech and his experiences using the platform (for the first time!). Siya Raj Purohit: Your team provides so many cool options for shoppers. How does Price.com function on the back end? Vasco Morais: Price.com’s proprietary algorithm and deep learning models make it possible for both structured and unstructured data to be matched, allowing for quick product matching and discovery to occur across several product types. This enables fun product features - for example, users just have to take a picture of a product they want to buy, and Price.com tells them the best place to buy it. To help provide this seamless service, we ingest and process data around the clock, using a sophisticated data pipeline. To prevent bad data and pricing errors from retailers from making it into our database, we have established a standard schema and put in a lot of effort (around the clock!) into ensuring everything adheres to the standard. SRP: How did the team decide to have Price.com #BuiltWithMongoDB? VM: From the beginning, the team knew that down the line, we would want to provide full support for all listings, including geospatial queries (which MongoDB has native support for). We also wanted to have the ability to easily create new indices as new functionality was added. That way, we could continuously query any product in our database and simultaneously update new data into our system without having to overcome read/write conflicts. We also wanted to have a platform that would scale with us. We’re processing billions of listings and price points and hosting on MongoDB gives us confidence. Finally, several team members had experience with MongoDB and felt close to MongoDB’s architecture — so it was an easy choice. SRP: When you joined Price.com as Director of Engineering, it was your first time using MongoDB. How was the onboarding process for you? VM: I had previously only worked with relational databases which opt for longer query construction as a trade-off for easy syntax and arguments. For example, doing something as simple as sorting (filtering) by timestamp can easily turn into a multi-line query in SQL, and it’s nice to see how simple it remains in MongoDB. Similarly, setting up a new collection in MongoDB was instantaneous compared to setting up and defining a schema for a new table in relational databases. I first looked at MongoDB documentation the night before I started at Price.com and felt fine working on the platform the next day. Every now and then, I would run into something that I would have to resolve with a Google search, but it definitely didn’t feel like the arduous use-it-or-lose-it skill set that accompanies other databases. Overall, for me and my team, MongoDB significantly cuts down the amount of time we spend on development when compared to other databases. Building something cool with MongoDB? Check out our developer resources , and let us know if you want your startup to be featured in our #BuiltWithMongoDB series.
Built with MongoDB: Interseller
We all think our jobs are hard. But if you’re a recruiter, you know just how tough it is to place people into those jobs: the average response rate to recruiters is an abysmal 7%. Enter Interseller , a fast-growing NYC-based SaaS company in the recruiting tech space. For this episode of #BuiltWithMongoDB, we go behind the scenes in recruiting technology with Steven Lu , co-founder and CEO of Interseller. How did you pick this problem to work on? While working as an engineer, I helped teach and recruit many other tech professionals. That’s when I realized that good engineers don’t find jobs. They get poached. Sourcing is essential for assembling great teams, but with the low industry response rate, I knew we needed a new solution. I started looking into recruiting technology and was frankly surprised by how outdated the solutions were. We began by addressing three parts of sourcing: Research Outreach Data Management To help us get started, Interseller went through Expa , Garrett Camp’s accelerator. We’ve been bootstrapping since then. We’re a team of 13, but we expect to grow to about 25 in another year. We serve about 4,000 recruiters, 75% of whom use us every single day. Some of our customers include Squarespace, Honey, and Compass. Overall, we have had about 2 million candidates respond to us, boosting our average response rate from the industry average of 7% to between 40% and 60%. We attempt to close candidates within 21 days. How did you decide to have Interseller #BuiltWithMongoDB? Like any engineer, I hate database migrations. I hate having to build around the database rather than the database building around my product. I remember using MongoDB at Compass in 2012—we were a MongoDB shop. After that, I went to another company that was using SQL and a relational database and I felt we were constantly being blocked by database migrations. I had to depend on our CTO to run the database migration before I could merge anything. I have such bad memories from that experience. I would rather have my engineering team push things faster than have to wait on the database side. MongoDB helped solve this. It worked well because it was so adaptable. I don’t know about scaling database solutions since we don’t have millions of users yet, but MongoDB has been a crucial part of getting core functionality, features, and bug fixes out much faster. Outside of MongoDB, we primarily use Node, Javascript, React, and AWS. Our release schedule is really short: as a startup, you have to keep pumping things out, and if half your time is spent on database migration, you won’t be able to serve customers. That’s why MongoDB Atlas is so core to our business. It’s reliable, and I don’t have to deal with database versions. Building something cool with MongoDB? Check out our developer resources , and let us know if you want your startup to be featured in our #BuiltWithMongoDB series.
Splitit & MongoDB Atlas: Racing to Capture a Global Opportunity
Splitit is a global payment solution that allows businesses to offer installment plans for their customers. Unlike with other buy now, pay later (BNPL) solutions, Splitit shoppers can split their online purchases into monthly installments by using their existing credit, without the need for registration, application, or approval. “We have a very different proposition than others in this space,” says Splitit’s CTO, Ran Landau. “We’re not a financing company. We utilize the customer’s existing credit card arrangement, which allows us to accommodate smaller average deal values and a broader range of installment schedules.” Splitit works with online retailers across all market sectors and diverse price points, and recently raised $71.5 million in investment to fund global expansion. Following its IPO in January 2019, the business had seen strong growth as more consumers moved from brick and mortar to ecommerce. Then COVID-19 hit, and online shopping boomed. Landau recognized that the company needed to quickly scale its infrastructure in order to capture this large opportunity. The Need for Speed Landau joined Splitit in May 2019 and worked to modernize the company’s infrastructure. At the time, the team was using a traditional relational database. “As tech leaders, we need to make the right decision,” he says. “When I came to Splitit, I knew I needed a powerful NoSQL server so that my developers could develop faster and so that we could scale – both things that our relational databases were failing to deliver.” In the interest of getting up and running quickly, Ran’s team thought that they could move faster using a cloud-provider database that mimicked MongoDB functionality. He had used MongoDB before and saw that this solution offered the same drivers he was familiar with and claimed compatibility with MongoDB 3.6. Initially, the new solution seemed fine. But as the team started to migrate more data into the database, however, Landau noticed a few missing features. Scripts for moving documents from one collection to another were failing, and overall performance was deteriorating. The application became slow and unresponsive even though the load on the database was normal. “We were having issues with small things, like renaming collections. I couldn’t search or navigate through documents easily,” recalls Landau. Offline Database: A Breaking Point Then one day, the application was unable to communicate with the database for 20 minutes, and when the database finally came back online, something wasn’t right. Landau contacted support, but the experience was not very helpful. “We were not pleased with the response from the database vendor,” he explains. “They insisted that the issue was on our side. It wasn’t so collaborative.” Fortunately, he had taken a snapshot of the data so Splitit was able to revert back to an earlier point in time. But the incident was troubling. Other teams also had been complaining about how difficult it was to debug problems and connect to the database successfully. Landau knew he needed to find a better solution as soon as possible. MongoDB Atlas: A Reliable, Scalable Solution Landau believed that MongoDB was still the right choice for Splitit, and investigated whether the company offered a cloud solution. He discovered MongoDB Atlas and decided to give it a try. “The migration to MongoDB Atlas was so simple. I exported whatever data I had, then imported it into the new cluster. I changed the connection strings and set up VPC peering in all of my environments,” says Landau. “It was incredibly easy.” Not only was MongoDB Atlas built on actual MongoDB database software, but it was also secure, easy to use, and offered valuable features such as Performance Advisor . “It can tell you which indexes need to be built to increase speed. It’s such a powerful tool — you don’t need to think; it analyzes everything for you,” explains Landau. Another great feature was auto-scaling. “My biggest concern as I scale is that things keep working. I don’t have to stop, evaluate, and maintain the components in my system,” says Landau. “If we go back to doing database operations, we can’t build new features to grow the business.” Auto-archival Made Easy with Online Archive As a business in the financial services industry, Splitit needs to comply with various regulations, including PCI DSS . A key requirement is logging every transaction and storing it for auditing purposes. For Splitit, that adds up to millions of logs per day. Landau knew that storing this data in the operational database was not a cost-effective, long-term solution, so he initially used an AWS Lambda function to move batches of logs older than 30 days from one collection to another periodically. A few months ago, he discovered Online Archive , a new feature released at MongoDB.live in June 2020. With it, Landau was able to define a simple rule for archiving data from a cluster into a more cost-effective storage layer and let Atlas automatically handle the data movement. “The gem of our transition to Atlas was finding Online Archive,” says Landau. “There’s no scripting involved and I don’t have to worry about my aging data. I can store years of logs and know that it’s always available if I need it.” Online Archive gives me the flexibility to store all of my data without incurring high costs, and feel safe that I won't lose it. It's the perfect solution. Ran Landau, CTO, Splitit With federated queries, the team can also easily analyze the data stored in both the cluster and the Online Archive for a variety of use cases. Ready for Hypergrowth and Beyond Looking back, Landau admits that he learned his lesson. In trying to move quickly, he selected a solution that appeared to work like MongoDB, but ultimately paid the price in reliability, features, and scalability. You wouldn't buy a fake shirt. You wouldn't buy fake shoes. Why buy a fake database? MongoDB Atlas is the real thing. Ran Landau, CTO, Splitit Landau is confident that his investment in MongoDB puts in place a core building block for the business’ continued success. With a fully managed solution, his team can focus on building features that differentiate Splitit from competitors to capture more of the market. “We saw our growth triple in March due to COVID-19, but the sector as a whole is expanding,” he says. “Our technology is patent protected. Everything we build moving forward will be on MongoDB. As a company that’s scaling rapidly, the most important thing is not having to worry about my scaling. MongoDB Atlas takes care of everything.”
Built with MongoDB: Sunsama
My co-founder Travis Meyer and I were both one year into our careers when it hit us that we would spend the next 40 years using tools such as Google Calendar and Microsoft Outlook to map out our time. That felt unacceptable. We wanted to build a productivity tool that’s more thoughtful and intentional so we can live a life that’s more thoughtful and intentional . That’s when we started working on Sunsama. Ashutosh Priyadarshy, Co-Founder, Sunsama Ashutosh Priyadarshy , founder of Sunsama , and I first met in 2017. At that time, he was building a meeting documentation tool. He soon saw significant churn and realized that users didn’t love the product, so Sunsama pivoted. Today, Sunsama is a Y Combinator-backed, invite-only daily task manager for busy professionals. Ashutosh says that in conversations with thousands of users, Sunsama found that people know what’s on their calendar, but also want to know how to think about their workday—how to answer the key question “what am I going to do today?” Sunsama gives users the ability to combine all tasks, meetings, to-dos, and JIRA tickets in a prioritized calendar, enabling professionals to be more mindful of how they spend their time. In this issue of #BuiltWithMongoDB, Ashutosh and I discuss his journey building Sunsama (including the pivots and successful fundraising) and how his team uses MongoDB to operate more efficiently. Siya Raj Purohit: How big is Sunsama now? Ashutosh Priyadarshy: We’re a team of five serving 2,000 active users. We graduated from YC in March 2019 and have since raised $2.4 million in seed money, were featured in TechCrunch and Cheddar, and were voted “Hot Product of the Month” on ProductHunt (read: Sunsama: If Trello & Google Calendar Had a Baby)” ). We’re growing 10 to 15% per month but generally limiting growth via invitations to ensure optimal user experience. SRP: Why is Sunsama #BuiltWithMongoDB? AP: We first decided to use MongoDB because a framework we wanted to use (Meteor) was tightly coupled with MongoDB. Our product doesn’t require all of the complexity of other database solutions, and MongoDB felt like a simple way to get started. Initially, we deployed MongoDB on AWS ourselves. But we’re a tiny team of five people, and it was time-consuming to manage DevOps. Upgrading to MongoDB Atlas was an easy decision because we would rather spend slightly more money and have zero headaches so we can spend all of our time building for customers instead of building for internal tooling and DevOps. As a young team, you just can’t afford to dedicate resources to second-order issues, so outsourcing to MongoDB Atlas made complete sense. Two or three years ago, we noticed that the MongoDB Atlas ecosystem was maturing beyond other tools out there: MongoDB added search, monitoring, and security features that were easy to set up. The timing was great: we were going through an audit with Google for getting our team integration approved, and Google looked at the entire surface area of the security app. Being able to plug and play—setting up the right type of encryption by just pressing a button—was really nice. We grew into MongoDB’s suite of products, and once we committed, we didn’t want to leave. SRP: What MongoDB services do you use? AP: We previously managed our own MongoDB deployment on Amazon EC2, and it was so much overhead. Our customers just wanted the product to work; they didn’t care about how our MongoDB instance was deployed. Thanks to MongoDB Atlas, we can focus on building things customers care about instead of maintaining our database. MongoDB is also moving in a direction we’re excited about that will provide direct value to our customers, especially with MongoDB 4.2 and the ability to run Elasticsearch queries directly in MongoDB. This means we can further simplify our stack and remove expensive Elasticsearch deployments that we’ve got in AWS and use the simple and clean alternatives MongoDB provides. Want to learn more about Sunsama? Request access here. Building something cool with MongoDB? Check out our developer resources , and let us know if you want your startup to be featured in our #BuiltWithMongoDB series.