Using database compare-exchange to synchronize accounts in an event management app. Learn how Sam Entertainment takes advantage of RavenDB’s NoSQL flexibility, compare-exchange values, and other advanced database features to deliver a seamless and memorable event experience for users.

Sam is an innovative event-based social media app for weddings and other social gatherings. Anyone planning an event can create a community specifically for the event itself. It provides a centralized platform for sharing pictures and videos, and helps attendees get to know each other before, during or after the event.

The app creates a digital space that complements the physical space, rather than distracting from it. Their ambition is to enhance social interaction, connect people, and collect authentic memories. 

Sam was developed by the Swiss company Sam Entertainment. The website and mobile app use RavenDB as the back end. This article is based on our interview with CTO Simon Birrer.

The app has a simplified, user friendly UX focused on sharing pictures. It also provides useful auxiliary features such as creating photo walls, games, and match-making between attendees based on shared interests.

The app has the rare ability to synchronize different login instances and merge them into one user. This way users’ information, their posts, and their RSVPs to events don’t get lost. You can log in with a Sam account, through google, through Facebook, or even use a QR code/dynamic link to join the event with no account at all.

While they’ve been very successful as a wedding app, they have no intention of being boxed in. Much of the development is focused on the needs of wedding organizers, but the same features can serve other events, or even a general online community – just like any other social media platform. In the coming months the team will have a strong focus on festivals, and is developing features to leverage festival communities even further.

History

The mobile app was launched on android on the last day of 2016. In 2020 the company was legally incorporated as SAM Entertainment AG.

At first they used PostgreSQL as the back end. Soon they added Marten, a code library that wraps postgres in a document database layer. This meant that objects from the application layer could be stored directly without having to conform to a schema. However, they encountered problems building a multi-master global network with Postgres, and they felt the Postgres offering on AWS was too expensive.

From there it was a smooth transition to the document database RavenDB. RavenDB stores data as JSON, the same format used by Marten, and which is supported by Postgres. They migrated their data around the end of January 2020.

Naturally, covid dealt Sam Entertainment a blow. But their user base continued to grow throughout the pandemic and they are now back on track with their global growth strategy.

RavenDB Experience

Configuration

Sam’s back end is written mainly in C# and uses RavenDB’s dotnet API. It is composed of around 15 microservices that communicate with RavenDB.

Three RavenDB clusters are hosted on AWS servers in the US, EU, and East Asia. As of March 2022, the European cluster records almost 3 million posts made by over half a million users.

They also have one on-premise instance of RavenDB. Simon says it is used as an “administrative backplane where we run RavenDB with the community license, where we do all the heavy lifting for number crunching of KPIs.” They also use it for batch processing.

Features

To convey data within and between their three global clusters, Sam Entertainment use ETL, external replication, and filtered replication. Without these features they “would have to write a lot of boilerplate synchronization code…These features make data replication the concern of the database rather than that of the developer.”

Filtered replication makes it very easy to choose which data gets replicated and which doesn’t – so that the global network can synchronize the globally relevant data. In contrast, most Sam communities consist of people and events in the same region, so their data doesn’t need to be replicated to other regions.

Another feature they like is Document Expiration, which they used to implement a rate limiter. This allows them to limit the number of push notifications their users get in a given time frame. It’s also handy in general for getting rid of data that is no longer important after an hour.

(Here is a tutorial by Kamran Ayub on how to implement rate limiting in RavenDB)

Sam uses document metadata quite heavily, which they call an “undervalued feature of Raven”. During indexing, documents can be filtered according to metadata tags. They implemented a custom soft-deletion flag which is used to delete data from the perspective of the application while preserving data in case there is a need to restore it. Soft deletion is only used for non-personally identifiable information.

The compare-exchange feature is core to one of Sam’s most unique and user-friendly features. If you log into the app in various ways – with google, with facebook, with a Sam account, or without any login information at all – the application is able to figure out that you’re still the same person. It preserves and unifies all your data from different logins. When you’ve joined an event, you can start to post anonymously before creating a profile and associating it with an email address or social media. This is useful for things like making sure people don’t RSVP an event more than once.

Compare-exchange is a highly efficient way to maintain the uniqueness of a value across the RavenDB cluster, enabling interlocked distributed operations. Sam also uses it to prevent simultaneous data migrations, so they occur in sequence and not in parallel. This aspect of compare-exchange is actually something that Simon personally contributed to.

Sam Entertainment haven’t used RavenDB Cloud so far (it did not exist when the app was first created). Simon says that “compared to other options out there I think it’s a really good approach. It comes with everything you need. Now with the telegraf integration you can actually also monitor things.”

Other features Sam Entertainment use frequently include:

• Counters
• Documents compression, which saves IOPS on the cloud.
• Changes API, a push notification service triggered whenever data is updated, and can be used to automate data processing and database operations.

Challenges with RavenDB

Simon describes how he “grew as a developer” along with RavenDB, so he had time to learn each new feature as it came along. More recently, as the company has grown, he’s realized that it can be an overwhelming experience for new developers. RavenDB has so many features now that a given problem can be solved with two or three different features, and then it’s a matter of choosing which. “Flexibility of choice is a pleasure”, but it’s mostly useful for people who are already experts. New users face those same choices but may not have the guidance they need to decide on the best course of action.

Sam Entertainment eagerly await the completion of RavenDB’s Grafana integration. As of the writing of this article, Grafana can be used to monitor RavenDB telemetry among other things. Soon it will be able to track the stored data itself. Grafana integration will be especially useful in combination with time series. Right now they are frustrated with having to maintain their monitoring UI on their own, and find it especially annoying to synchronize the time frames displayed by different widgets. “The operations aspect is the missing part,” as well as OpenTelemetry integration.

For each query, RavenDB exposes query timings which display the duration of the different stages of query execution. Simon suggests extending this approach to end-to-end instrumentation would be helpful. Beyond Grafana helping to monitor the client, there should also be monitoring for the client side, identifying outlier queries that take longer than normal, doing postmortem analysis, etc. They would like to be able to relate the query with the microservice it came from.

Simon told us that: “RavenDB’s clustering itself is so bulletproof that it just runs – but you’re not aware most of the time that your cluster is having a hard time. SNMP and Prometheus integration is all nice and fine, but how do you know if the cluster is in danger? For someone that needs to operate the cluster – when do I actually need to get up in the night?”

He went on to ask “There are really nice notifications already in RavenDB Studio, but those you only get if you are connected to the Studio, right? So maybe some way transferring those into for instance Slack notifications would already bring massive benefits on our end.”

We at RavenDB thought this was an excellent point, and will be adding this to our list of planned features.

Future plans

Sam Entertainment have great plans for RavenDB’s time-series capabilities. They can use them for coarse grained metrics and KPI tracking. Time-series may replace document expiration as the basis of the rate limiting mentioned earlier, as Simon thinks it will be “a more scalable approach”. Incremental time series may be especially helpful there.

In the near future they’re planning to add gamification features. With the rebranding last May and the ongoing conversations with big partners the app will be used for so much more than just weddings. It works great for birthdays, business get-togethers, anniversaries, festivals, and more.

We really appreciate everything Sam Entertainment have done to make RavenDB the best database it can be, and look forward to continuing supporting them in the future.