Built With MongoDB: Alloy Transforms Ecommerce With No-Code Integrations

Steve Jurczak
August 31, 2022 | Updated: October 17, 2022
#BuiltWithMongoDB#Startups

Gregg Mojica and Sara Du knew there was a need for simpler integrations with ecommerce platforms because they had experienced it themselves. After becoming friends through the open source community, they started a Shopify store as a side project and became intrigued by the multitude of apps available in the Shopify ecosystem — a large selection of integrations for things like ERP, email and social media marketing, ads, marketing analytics, and more. Mojica and Du also found that stitching together these disparate tools was overly complex and that the tools were not geared toward ecommerce.

Their company, Alloy Automation, is a no-code integration solution that integrates with and automates ecommerce services, such as CRM, logistics, subscriptions, and databases. For example, Alloy can automate SMS messages to go out upon reaching fulfillment milestones. It can automatically start a workflow when an event occurs in an online store or in another app, create logic to define whether a follow-up action will be taken, and use conditions like order tags or customer location to set up automated actions that will pull and push data from connected apps. If order status is updated to paid and the total value of order is greater than $100, for example, Alloy Automation can automatically send a text message with a discount for an additional purchase.

Alloy is part of the MongoDB for Startups program, and this article looks at how Alloy uses MongoDB and also benefits from the partnership to overcome startup challenges.

Jobs to be done

Mojica, co-founder and CTO of Alloy, sympathized with merchants that were trying to connect multistage workflows using the limited tools that were available. "A lot of merchants have relatively complex flows," he said. "They're cycling through abandoned carts, checking if certain line items are present, and setting up very aggressive rules that historically you would have to program yourself. But a lot of merchants don't have the operating budget to hire expensive engineers to set up these rules."

Mojica applied the knowledge he had gained as an engineer in financial services to address the integration problems he and Du were experiencing as online merchants. Although Alloy was initially focused on solving general ecommerce problems, Mojica says he realized that the tools he was building could apply to more than just ecommerce. "Not only are we solving problems for merchants but also for software and SaaS companies," Mojica said. "Now anybody can build relatively complex automations without having engineering expertise. Alloy can templatize those things and offer them as recipes on our platform – we offer a business facing product called Alloy Embedded that allows anyone to effortlessly connect to our integrations by implementing our SDK. Businesses can get started very easily with just a few lines of code."

Early stages

Alloy is a Y Combinator company — part of the cohort that was scheduled to demo their products in March 2020, the very moment the world “locked down” because of the COVID-19 pandemic. It still raised $5 million in a seed round, followed by $20 million in Series A funding in February 2022. In that time, the company has expanded its platform to include more than 220 integrations, including MongoDB.

Alloy is a member of the MongoDB for Startups program, which provides Atlas credits among other benefits for young companies, and it uses MongoDB Atlas as the underlying database. Mojica cites several reasons for the close partnership between the two companies. "Atlas was the database we chose from the beginning. I personally have used MongoDB before, so I have a certain comfort level, and I was the first person that wrote code in Alloy," Mojica said. "But another big reason why I wanted to use MongoDB is the freeform nature of much of the data that we ingest. We connect over 220 integrations, each one has its own schema, and it's typically in JSON. So having a less structured way to store that information compared with something highly delineated like SQL has been very valuable to us."

Growing pains

Mojica and Du are acutely aware of the challenges startups face, especially managing technical resources. "We like the fact that MongoDB has really good support, there's built-in monitoring, and backups,” Mojica said. “These things allow you to get going quickly. There's a lot of pressure, especially in the very beginning, to get into Y Combinator. You've got to build the product, get customers, and start your fundraise. That's a lot to do in three months. What you don't want to worry about is all the DevOps stuff."

As startups begin to scale, they often become subject to compliance requirements that present new technology hurdles. Alloy went through the compliance process seamlessly thanks to the security capabilities and certifications behind MongoDB Atlas.

"We're servicing larger clients and seeing different use cases," Mojica said. "The compliance process involved questions about where we're storing data and if we're in different regions. Once your company is big enough, it's a major concern. Just having SOC 2 certification and making sure we're following all the various data privacy rules is really important. We're effectively an intermediary for customer data, so compliance is really important, like when we are deleting data for GDPR requests. MongoDB Atlas helps us with that. It's SOC 2 certified, and we can deploy in any region on any of the major cloud providers. For us, that meant setting up a Network Peering Connection to our AWS VPC from Atlas. So, from a security and compliance perspective, we know that's all taken care of."

Making the MongoDB connection

"We added a MongoDB connector to our platform because we were hearing interest from our user base,” Mojica explained. “If you want to integrate with a series of different tools and you're also sending data to MongoDB Atlas, instead of having to build those integrations every time, Alloy already has the infrastructure. You can just connect your system, stream the data, and we handle all the architecture. Something that would normally take weeks or months now takes only a few hours. That's the power of the no-code platform."

The Alloy–MongoDB integration includes bidirectional sync. "Your connection with MongoDB Atlas can go both ways,” Mojica added. “You can pull data and you can push data. You can do scheduled workflows once an hour or once a day, make a query, get some data from MongoDB, check if a record was added, and then send the data to another platform or destination. The bidirectional sync is really important, because integration really is the ability to get data, but also push data."

Support for startups

As a member of the MongoDB for Startups program, Alloy enjoys access to a wide range of resources, including free credits to our best-in-class developer data platform, MongoDB Atlas, and personalized technical advice, among other perks. Alloy leveraged the program from an early stage, as Mojica explained, "The credits were very helpful in the beginning, especially when you're in Y Combinator and don't have a lot of money in the bank. We recently started getting in touch for support. In fact, just knowing that we have support is very valuable."

To learn more about Alloy, check out runalloy.com.

Are you part of a startup and interested in joining the MongoDB for Startups program? Apply now.

← Previous

3 Reasons (and 2 Ways) to Use MongoDB’s Improved Time Series Collections

Time series data, which reflects measurements taken at regular time intervals, plays a critical role in a wide variety of use cases for a diverse range of industries. For example, park management agencies can use time series data to examine attendance at public parks to better understand peak times and schedule services accordingly. Retail companies, such as Walmart , depend on it to analyze consumer spending patterns down to the minute, to better predict demand and improve shift scheduling, hiring, warehousing, and other logistics. As more sensors and devices are added to networks, time series data and its associated tools have become more important . In this article, we’ll look at three reasons (and two ways) to use MongoDB time series collections in your stack. This in-depth introduction to time series data features MongoDB Product Manager Michael Gargiulo. Reason 1: Purpose-built for the challenges of time series data At first glance, time series collections resemble other collections within MongoDB, with similar functionalities and usage. Beneath the surface, however, they are specifically designed for storing, sorting, and working with time series data. For developers, query speed and data accessibility continue to be challenges associated with time series data. Because of how quickly time series data can accumulate, it must be organized and sorted in a logical way to ensure that queries and their associated operations can run smoothly and quickly. To address this issue, time series collections implement a key tenet of the MongoDB developer data platform: Data that is stored together is accessed together. Documents (the basic building block of MongoDB data) are grouped into buckets, which are organized by time. Each bucket contains time series data from a variety of sources — all of which were gathered from the same time period and all of which are likely to show up on the same queries. For example, if you are using time series collections to analyze the rise in summer temperatures of Valencia, Spain from 1980 to 2020, then one bucket will contain temperatures for August 1991. Relevant, but distinct buckets (such as temperatures for the months of June and July 1991) would also be stored on the same page for faster, easier access. MongoDB also lets you create compound indexes on any measurement field in the bucket (whether it’s timeField or metaField) for faster, more flexible queries. Because of the wide variety of indexing options, operations on time series data can be executed much more quickly than with competing products. For example, scan times are reduced by indexing buckets of documents (each of which has a unique identifier) rather than individual documents. In terms of the previous example, you could create an index on the minimum and maximum average summer temperatures in Valencia, Spain from 1980 to 2020 to more quickly surface necessary data. That way, MongoDB does not have to scan the entire dataset to find min and max values over a period of nearly four decades. Another concern for developers is finding the last metadata value, which in other solutions, requires users to scan the entire data set — a time-consuming process. Instead, time series collections use last point queries, where MongoDB simply retrieves the last measurement for each metadata value. As with other fields, users can also create indexes for last points in their data. In our example, you could create an index to identify the end of summer temperatures in Valencia from 1980 to 2020. By indexing the last values, time series collections can drastically reduce query times. Another recurring challenge for time series applications is data loss from Internet of Things (IoT) applications for industries such as manufacturing, meteorology, and more. As sensors go offline and gaps in your data appear, it becomes much more difficult to run analytics, which require a continuous, uninterrupted flow of data. As a solution, the MongoDB team created densification and gap filling. Densification, executed by the $densify command, creates blank, placeholder documents to fill in any missing timestamps. Users can then sort data by time and run the $fill command for gap filling. This process will estimate and add in any null or missing values in documents based on existing data. By using these two capabilities in tandem, you will get a steady flow of data to input into aggregation pipelines for insights. Reason 2: Keep everything in house, in one data platform Juggling different data tools and platforms can be exhausting. Cramming a bunch of separate products and technologies into a single infrastructure can create complex architectures and require significant operational overhead. Additionally, a third-party time series solution may not be compatible with your existing workflows and may necessitate more workarounds just to keep things running smoothly. The MongoDB developer data platform brings together several products and features into a single, intuitive ecosystem, so developers can use MongoDB to address many common needs — from time series data to change streams — while reducing time-consuming maintenance and overhead. As a result, users can take advantage of the full range of MongoDB features to collect, analyze, and transform time series data. You can query time series collections through the MongoDB Compass GUI or the MongoDB Shell , utilize familiar MongoDB capabilities like nesting data within documents, secondary indexes, and operators like $lookup or $merge, and process time series data through aggregation pipelines to extract insights and inform decision making. Reason 3: Logical ways to organize and access time series data Time series collections are designed to be efficient, effective, and easy to use. For example, these collections utilize a columnar storage format that is optimized for time series data. This approach ensures efficiency in all database operations, including queries, input/output, WiredTiger cache usage, and storage footprints for both data and secondary indexes. Let’s look, for example, at how querying time series data collections works. When a query is executed, two things happen behind the scenes: Bucket unpacking and query rewrites. To begin with, time series collections will automatically unpack buckets — similar to the $unwind command. MongoDB will unscroll compressed data, sort it, and return it to the format in which it was inserted, so that it is easier for users to read and parse. Query rewrites work alongside bucket unpacking to ensure efficiency. To avoid unpacking too many documents (which exacts a toll in time and resource usage), query rewrites use indexes on fields such as timestamps to automatically eliminate buckets that fall outside the desired range. For example, if you are searching for average winter temperatures in Valencia, Spain from 1980 to 2020, you can exclude all temperatures from the spring, summer, and fall months. Now that we’ve examined several reasons to consider MongoDB time series collections, we’ll look at two specific use cases. Use case 1: Algorithmic trading Algorithmic trading is a major use case for time series data, and this market is predicted to grow to $15 billion by 2028 . The strength of algorithms lies in their speed and automation; they reduce the possibility of mistakes stemming from human emotions or reaction time and allow for trading frequency beyond what a human can manage. Trading algorithms also generate vast volumes of time series data, which cannot necessarily be deleted, due to compliance and forecasting needs. MongoDB, however, lets you set archival parameters, to automatically move that data into cheaper cloud object storage after a preset interval of time. This approach preserves your valuable storage space for more recent data. Using MongoDB products such as Atlas, materialized views, time series collections, and triggers, it is also possible to build a basic trading algorithm. Basically, time series data will be fed into this algorithm, and when the conditions are ideal, the algorithm can buy or sell as needed, thus executing a series of individual trades with cumulative profits and losses (P&L). Although you’ll need a Java app to actually execute the trades, MongoDB can provide a strong foundation on which to build. The structure of such an algorithm is simple. Time series data is loaded from a live feed into MongoDB Atlas, which will then input it into a materialized view to calculate the averages that will serve as the basis of your trades. You can also add a scheduled trigger to execute when new data arrives, thereby refreshing your materialized views, keeping your algorithm up to date, and not losing out on any buying/selling opportunities. To learn more, watch Wojciech Witoszynski’s MongoDB World 2022 presentation on building a simple trading algorithm using MongoDB Atlas, “Algorithmic Trading Made Easy.” Use case 2: IoT Due to the nature of IoT data, such as frequent sensor readings at fixed times throughout a day, IoT applications are ideally suited for time series collections. For example, Confluent, a leading streaming data provider, uses its platform alongside MongoDB Atlas Device Sync , mobile development services, time series collections, and triggers to gather, organize, and analyze IoT data from edge devices. IoT apps often feature high volumes of data taken over time from a wide range of physical sensors, which makes it easy to fill in meta fields and take advantage of densification and gap filling features as described above. MongoDB’s developer data platform also addresses many of the challenges associated with IoT use cases. To begin with, MongoDB is highly scalable, which is an important advantage, given the huge volumes of data generated by IoT devices. Furthermore, MongoDB includes key features to enable you to make the most of your IoT data in real time. These include change streams for identifying database events as they occur, or functions, which can be pre-scheduled or configured to execute instantaneously to respond to database changes and other events. For users dealing with time-based data, real-time or otherwise, MongoDB’s time series collections offer a seamless, highly optimized way to accelerate operations, remove friction, and use tools, such as triggers, to further analyze and extract value from their data. Additionally, users no longer have to manually bucket, query, or otherwise troubleshoot time series data; instead, MongoDB does all that work for them. Try MongoDB time series collections for free in MongoDB Atlas .

August 30, 2022
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024