AO.com Turns to MongoDB to Build a Single Customer View

MongoDB
August 22, 2018 | Updated: May 24, 2021
#Customer Stories

Transforms customer experience, fights fraud, and meets the demands of the GDPR with MongoDB Atlas and Apache Kafka running on AWS

In a world where standards and speed in online retail are getting ever higher, one retailer, AO.com has consistently been able to differentiate itself around its core focus: customer experience.

At the beginning of 2017 it was clear there was a big opportunity to use customer data more effectively, to drive:

  1. Continued improvement to the customer experience
  2. Faster identification of fraud
  3. Compliance with the EU’s new GDPR personal privacy regulations

AO responded by starting a new team, giving them the mandate to build a 360-degree single view platform of all its customer data.

To ensure they could move quickly and keep the team focused on business goals, the team chose to use MongoDB Atlas in the cloud. We spoke with Jon Vines, Software Development Team Lead at AO.com, about the experience of building the single customer view application, his development philosophy, and the impact it’s having at AO.

Can you start by telling us about AO.com?

AO.com is one of the UK’s leading online electrical retailers. At AO, what really drives us and makes us special is how obsessed we are with the customer’s experience. We make sure that our employees are empowered to make the call on what’s best for each and every customer, that means no scripts or rules in the contact centre, we just do what we think is right. Our guide has always been to ask whether our mum would be proud of the decisions we make every day and whether we feel we would have treated our own Nan in the same way.

That philosophy extends right through to the core technology decisions we make. For instance, the third of our three core business model pillars is infrastructure. We know it’s incredibly important to have systems that are scalable and extendable while making sure we get all the benefit of operational gearing and pace from our investments and long-term growth.

With quality infrastructure as such a key part of AO’s strategy, what was your team trying to achieve?

We were tasked with pulling together the many sources of customer information within AO, to build a single, holistic view of each of our customers. Our data is spread across many different departments, each using their own technology.

The ultimate goal is to deliver one source of truth for all customer data – to drive a host of new and enhanced applications and business processes. This enables our staff, with the appropriate permissions, to access all the useful data we have at the company, from one single place, and all from one easy to consume operational data layer.

Can you tell us a little bit about what apps will consume the single view?

There are three core apps we are serving today:

  • Call center: For us, it is all about the customer and relentlessly striving to make our customers happy. Evaluating our contact centre systems showed us that we could enhance our customer journey by exposing more data points that were not currently available to our agents. This allows us to provide a better level of customer experience.
  • Fraud: Anything in the fraud grey area gets passed to our fraud team for the personal touch. As our company grows, we’re constantly looking for ways to be more efficient and effective. This is where the single view comes in. The high-throughput, low-latency capabilities and the aggregation of multiple disparate data sources makes it the perfect vehicle to provide additional decision support and anomaly detection for our fraud team.
  • GDPR: We need to be able to tell customers what personal data we store about them. Our marketing teams need to be able to see customer’s preferences in relation to communications with us. The single view makes all of this much easier.

This is just the start. There are many more projects that are under development.

So how did you get started with the single view project?

The team was formed in May 2017, and our first task was to identify source data and define the domain we were operating in. We have a lot of historical data assets that need to be blended with real-time data. This meant working with multiple instances of Microsoft SQL Server, and various data repositories and message queues hosted on Amazon Web Services (AWS), including SQS. We had to figure out a way to extract that data cleanly, without impacting source systems.

We spent several months cataloging our data assets, before turning to prototyping and technology selection. We started development in October 2017 and went into production just three months later in January 2018. The key to this development velocity was the underlying technology we selected to power the single view platform.

What are you using to move data from your source systems?

As a business we were already running in AWS, so we first looked at Kinesis, but decided on using Apache Kafka and Confluent Open Source. We can use Kafka’s Connect API to extract data via the Change Data Capture streams on existing data sources, with Kafka streaming and transforming the source data into our single view data model. This allows us to extract data without creating dependencies on other teams who we would otherwise have to rely upon to publish this data, or give us access to their source systems.

Once the data is in Kafka, it opens up a multitude of potential downstream applications. The single customer view is just the first of these. We can also use the oplog in MongoDB to extract data into Kafka, which allows us to decouple our microservices architecture in a very natural way.

How about the database layer?

It was clear that legacy relational databases would never give the schema flexibility we needed, so we explored more modern database options.

We explored a number of different non-tabular databases before choosing MongoDB. It soon became clear that MongoDB’s document model was the best choice for us. It supports rich customer objects that we can further enrich at any stage without expensive schema migrations. And strongly typed temporal data formats are valuable for our app. In terms of overall functionality, for our use case, MongoDB was the clear choice to help us achieve our goals.

We also found MongoDB’s 10-step methodology guide to building a single view – it was clear many customers had done this before with MongoDB – and they offered a unique blend of expertise, processes, and technology to help us deliver.

Taking all of this onboard, it took less than a day to move our data and code from an early prototype system to MongoDB, and from there, we didn’t look back.

Can you tell us why you decided to run on MongoDB Atlas?

We are a small DevOps team with three developers and a business analyst. We own the single view platform end to end, from prototyping and development through to deployment, security, and ongoing operations. We need to focus on meeting the needs of the business, not on managing the database, and Atlas gives us that. All of the operational best practices are baked in. We don’t have to worry about database operations, monitoring or backups. Atlas automates all of those services, which fits perfectly with our developer-first ethos at AO.com.

How is MongoDB Atlas performing for you?

Atlas has been rock solid since launch. We are running a replica set in AWS Ireland, with the ability to scale up and out on-demand, with no application downtime. This is especially valuable as we are currently managing millions of orders and customer objects in the single view platform, and are now planning to add clickstream data, which will significantly grow the data under management.

We can serve complex queries in around 10ms and writes at 5ms. The Atlas alerting is great – we get instant notifications if anything needs attention, and we can add our own custom alerts as needed. The Performance Advisor has been hugely valuable to the team – any unindexed queries are captured and alerted to us, so we can add a new index in minutes if we need to. Collectively, these features mean we can react in real time to anything that happens in our production environment.

We are also planning to start using the MongoDB Connector for BI to visualize metrics from all customer data that is onboarded to the single view.

Can you tell us more about the development philosophy at AO.com?

Really it’s all around the theme of getting products delivered for the business. Our philosophy subscribes to ‘The Three Ways’:

  1. Flow from left to right – we are focused on getting ideas into production as quickly as possible. We are reducing dependencies between teams, investing in continuous integration and delivery tools, and making smart technology choices to improve developer productivity. Our goal is to go from code commit to production in less than 30 minutes.
  2. Amplifying feedback loops – building processes so we can continually work with the business to identify what’s working and what’s not.
  3. Continuous improvement – validating hypotheses early, using feedback loops and making changes. We are moving towards chaos engineering. MongoDB Atlas has been a great asset on that as it allows us to trigger failover experiments and other conditions to improve code and platform resilience.

If that sounds like the sort of development team you want to work with, then we are hiring!

Finally, how are you measuring the impact of the single view platform on the business?

It’s still the early stages and we see this having a number of major benefits to the business. In the short term we’re focusing on a couple of very concrete metrics:

  • Call centre experience – we are able to reduce the number of times a customer needs to call as our agents can access all of the data they need immediately. We’re also working to help reduce the average call handling time by up to 40%.
  • Fraud – we’re helping to improve fraud detection lead time and be proactive in monitoring potential fraud trends. We’re also lowering the rejection rate and reducing the number of false positives. All of which frees up resource and, crucially, improves customer experience.
  • GDPR compliance – obviously there are many teams involved in making sure we were ready for this, but ensuring we have a platform in place that can easily answer the questions from the legal department has been crucial.

Of course, this is all just the beginning. Next, we’ll be looking at data analysis, exposing the single view data as a service to more applications, and automating more business processes.

Jon, thanks for sharing your story with the MongoDB community

And if you want to find out more and see Jon present at MongoDB Europe, then reserve your tickets here. Use the code AO20 to get 20% off

To get started with your own single view project, download our 10-Step Methodology Guide

← Previous

Java and MongoDB 4.0 Support for Multi-Document ACID Transactions

Introduction MongoDB 4.0 adds support for multi-document ACID transactions. But wait... Does that mean MongoDB did not support transactions until now? No, actually MongoDB has always supported transactions in the form of single document transactions. MongoDB 4.0 extends these transactional guarantees across multiple documents, multiple statements, multiple collections, and multiple databases. What good would a database be without any form of transactional data integrity guarantee? Before we dive into this blog post, you can find all the code and try multi-document ACID transactions here . Quick start Step 1: Start MongoDB Start a single node MongoDB ReplicaSet in version 4.0.0 minimum on localhost, port 27017. If you use Docker: You can use start-mongo.sh . When you are done, you can use stop-mongo.sh . If you want to connect to MongoDB with the Mongo Shell, you can use connect-mongo.sh . If you prefer to start mongod manually: mkdir /tmp/data && mongod --dbpath /tmp/data --replSet rs mongo --eval 'rs.initiate()' Step 2: Start Java This demo contains two main programs: ChangeStreams.java and Transactions.java . Change Steams allow you to be notified of any data changes within a MongoDB collection or database. The Transaction process is the demo itself. You need two shells to run them. If you use Docker: First shell: ./compile-docker.sh ./change-streams-docker.sh Second shell: ./transactions-docker.sh If you do not use Docker, you will need to install Maven 3.5.X and a JDK 10 (or JDK 8 minimum but you will need to update the Java versions in the pom.xml): First shell: ./compile.sh ./change-streams.sh Second shell: ./transactions.sh Let’s compare our existing single document transactions with MongoDB 4.0’s ACID compliant multi-document transactions and see how we can leverage this new feature with Java. Prior to MongoDB 4.0 Even in MongoDB 3.6 and earlier, every write operation is represented as a transaction scoped to the level of an individual document in the storage layer. Because the document model brings together related data that would otherwise be modeled across separate parent-child tables in a tabular schema, MongoDB’s atomic single-document operations provide transaction semantics that meet the data integrity needs of the majority of applications. Every typical write operation modifying multiple documents actually happens in several independent transactions: one for each document. Let’s take an example with a very simple stock management application. First of all, I need a MongoDB Replica Set so please follow the instructions given above to start MongoDB. Now let’s insert the following documents into a product collection: MongoDB Enterprise rs:PRIMARY> db.product.insertMany([ { "_id" : "beer", "price" : NumberDecimal("3.75"), "stock" : NumberInt(5) }, { "_id" : "wine", "price" : NumberDecimal("7.5"), "stock" : NumberInt(3) } ]) Let’s imagine there is a sale on and we want to offer our customers a 20% discount on all our products. But before applying this discount, we want to monitor when these operations are happening in MongoDB with Change Streams. Execute the following in Mongo Shell: cursor = db.product.watch([{$match: {operationType: "update"}}]); while (!cursor.isExhausted()) { if (cursor.hasNext()) { print(tojson(cursor.next())); } } Keep this shell on the side, open another Mongo Shell and apply the discount: PRIMARY> db.product.updateMany({}, {$mul: {price:0.8}}) { "acknowledged" : true, "matchedCount" : 2, "modifiedCount" : 2 } PRIMARY> db.product.find().pretty() { "_id" : "beer", "price" : NumberDecimal("3.00000000000000000"), "stock" : 5 } { "_id" : "wine", "price" : NumberDecimal("6.0000000000000000"), "stock" : 3 } As you can see, both documents were updated with a single command line but not in a single transaction. Here is what we can see in the Change Stream shell: { "_id" : { "_data" : "825B4637290000000129295A1004374DC58C611E4C8DA4E5EDE9CF309AC5463C5F6964003C62656572000004" }, "operationType" : "update", "clusterTime" : Timestamp(1531328297, 1), "ns" : { "db" : "test", "coll" : "product" }, "documentKey" : { "_id" : "beer" }, "updateDescription" : { "updatedFields" : { "price" : NumberDecimal("3.00000000000000000") }, "removedFields" : [ ] } } { "_id" : { "_data" : "825B4637290000000229295A1004374DC58C611E4C8DA4E5EDE9CF309AC5463C5F6964003C77696E65000004" }, "operationType" : "update", "clusterTime" : Timestamp(1531328297, 2), "ns" : { "db" : "test", "coll" : "product" }, "documentKey" : { "_id" : "wine" }, "updateDescription" : { "updatedFields" : { "price" : NumberDecimal("6.0000000000000000") }, "removedFields" : [ ] } } As you can see the cluster times (see the clusterTime key) of the two operations are different: the operations occurred during the same second but the counter of the timestamp has been incremented by one. Thus here each document is updated one at a time and even if this happens really fast, someone else could read the documents while the update is running and see only one of the two products with the discount. Most of the time, it is something you can tolerate in your MongoDB database because, as much as possible, we try to embed tightly linked, or related data in the same document. As a result, two updates on the same document happen within a single transaction : PRIMARY> db.product.update({_id: "wine"},{$inc: {stock:1}, $set: {description : "It’s the best wine on Earth"}}) WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 }) PRIMARY> db.product.findOne({_id: "wine"}) { "_id" : "wine", "price" : NumberDecimal("6.0000000000000000"), "stock" : 4, "description" : "It’s the best wine on Earth" } However, sometimes, you cannot model all of your related data in a single document, and there are a lot of valid reasons for choosing not to embed documents. MongoDB 4.0 with multi-document ACID transactions Multi-document ACID transactions in MongoDB are very similar to what you probably already know from traditional relational databases. MongoDB’s transactions are a conversational set of related operations that must atomically commit or fully rollback with all-or-nothing execution. Transactions are used to make sure operations are atomic even across multiple collections or databases. Thus, with snapshot isolation reads, another user can only see all the operations or none of them. Let’s now add a shopping cart to our example. For this example, 2 collections are required because we are dealing with 2 different business entities: the stock management and the shopping cart each client can create during shopping. The lifecycle of each document in these collections is different. A document in the product collection represents an item I’m selling. This contains the current price of the product and the current stock. I created a POJO to represent it : Product.java. { "_id" : "beer", "price" : NumberDecimal("3"), "stock" : NumberInt(5) } A shopping cart is created when a client adds its first item in the cart and is removed when the client proceeds to checkout or leaves the website. I created a POJO to represent it : Cart.java. { "_id" : "Alice", "items" : [ { "price" : NumberDecimal("3"), "productId" : "beer", "quantity" : NumberInt(2) } ] } The challenge here resides in the fact that I cannot sell more than I possess: if I have 5 beers to sell, I cannot have more than 5 beers distributed across the different client carts. To ensure that, I have to make sure that the operation creating or updating the client cart is atomic with the stock update. That’s where the multi-document transaction comes into play. The transaction must fail in the case someone tries to buy something I do not have in my stock. I will add a constraint on the product stock: db.createCollection("product", { validator: { $jsonSchema: { bsonType: "object", required: [ "_id", "price", "stock" ], properties: { _id: { bsonType: "string", description: "must be a string and is required" }, price: { bsonType: "decimal", minimum: 0, description: "must be a positive decimal and is required" }, stock: { bsonType: "int", minimum: 0, description: "must be a positive integer and is required" } } } } }) Node that this is already included in the Java code. To monitor our example, we are going to use MongoDB Change Streams that were introduced in MongoDB 3.6. In each of the threads of this process called ChangeStreams.java , I am going to monitor one of the 2 collections and print each operation with its associated cluster time. // package and imports public class ChangeStreams { private static final Bson filterUpdate = Filters.eq("operationType", "update"); private static final Bson filterInsertUpdate = Filters.in("operationType", "insert", "update"); private static final String jsonSchema = "{ $jsonSchema: { bsonType: \"object\", required: [ \"_id\", \"price\", \"stock\" ], properties: { _id: { bsonType: \"string\", description: \"must be a string and is required\" }, price: { bsonType: \"decimal\", minimum: 0, description: \"must be a positive decimal and is required\" }, stock: { bsonType: \"int\", minimum: 0, description: \"must be a positive integer and is required\" } } } } "; public static void main(String[] args) { MongoDatabase db = initMongoDB(args[0]); MongoCollection<Cart> cartCollection = db.getCollection("cart", Cart.class); MongoCollection<Product> productCollection = db.getCollection("product", Product.class); ExecutorService executor = Executors.newFixedThreadPool(2); executor.submit(() -> watchChangeStream(productCollection, filterUpdate)); executor.submit(() -> watchChangeStream(cartCollection, filterInsertUpdate)); ScheduledExecutorService scheduled = Executors.newSingleThreadScheduledExecutor(); scheduled.scheduleWithFixedDelay(System.out::println, 0, 1, TimeUnit.SECONDS); } private static void watchChangeStream(MongoCollection<?> collection, Bson filter) { System.out.println("Watching " + collection.getNamespace()); List<Bson> pipeline = Collections.singletonList(Aggregates.match(filter)); collection.watch(pipeline) .fullDocument(FullDocument.UPDATE_LOOKUP) .forEach((Consumer<ChangeStreamDocument<?>>) doc -> System.out.println( doc.getClusterTime() + " => " + doc.getFullDocument())); } private static MongoDatabase initMongoDB(String mongodbURI) { getLogger("org.mongodb.driver").setLevel(Level.SEVERE); CodecRegistry providers = fromProviders(PojoCodecProvider.builder().register("com.mongodb.models").build()); CodecRegistry codecRegistry = fromRegistries(MongoClient.getDefaultCodecRegistry(), providers); MongoClientOptions.Builder options = new MongoClientOptions.Builder().codecRegistry(codecRegistry); MongoClientURI uri = new MongoClientURI(mongodbURI, options); MongoClient client = new MongoClient(uri); MongoDatabase db = client.getDatabase("test"); db.drop(); db.createCollection("cart"); db.createCollection("product", productJsonSchemaValidator()); return db; } private static CreateCollectionOptions productJsonSchemaValidator() { return new CreateCollectionOptions().validationOptions( new ValidationOptions().validationAction(ValidationAction.ERROR).validator(BsonDocument.parse(jsonSchema))); } } In this example we have 5 beers to sell. Alice wants to buy 2 beers but we are not going to use the new MongoDB 4.0 multi-document transactions for this. We will observe in the change streams two operations : one creating the cart and one updating the stock at 2 different cluster times. Then Alice adds 2 more beers in her cart and we are going to use a transaction this time. The result in the change stream will be 2 operations happening at the same cluster time. Finally, she will try to order 2 extra beers but the jsonSchema validator will fail the product update and result in a rollback. We will not see anything in the change stream. Here is the Transaction.java source code: // package and import public class Transactions { private static MongoClient client; private static MongoCollection<Cart> cartCollection; private static MongoCollection<Product> productCollection; private final BigDecimal BEER_PRICE = BigDecimal.valueOf(3); private final String BEER_ID = "beer"; private final Bson stockUpdate = inc("stock", -2); private final Bson filterId = eq("_id", BEER_ID); private final Bson filterAlice = eq("_id", "Alice"); private final Bson matchBeer = elemMatch("items", eq("productId", "beer")); private final Bson incrementBeers = inc("items.$.quantity", 2); public static void main(String[] args) { initMongoDB(args[0]); new Transactions().demo(); } private static void initMongoDB(String mongodbURI) { getLogger("org.mongodb.driver").setLevel(Level.SEVERE); CodecRegistry codecRegistry = fromRegistries(MongoClient.getDefaultCodecRegistry(), fromProviders( PojoCodecProvider.builder().register("com.mongodb.models").build())); MongoClientOptions.Builder options = new MongoClientOptions.Builder().codecRegistry(codecRegistry); MongoClientURI uri = new MongoClientURI(mongodbURI, options); client = new MongoClient(uri); MongoDatabase db = client.getDatabase("test"); cartCollection = db.getCollection("cart", Cart.class); productCollection = db.getCollection("product", Product.class); } private void demo() { clearCollections(); insertProductBeer(); printDatabaseState(); System.out.println("######### NO TRANSACTION #########"); System.out.println("Alice wants 2 beers."); System.out.println("We have to create a cart in the 'cart' collection and update the stock in the 'product' collection."); System.out.println("The 2 actions are correlated but can not be executed on the same cluster time."); System.out.println("Any error blocking one operation could result in stock error or beer sale we don't own."); System.out.println("---------------------------------------------------------------------------"); aliceWantsTwoBeers(); sleep(); removingBeersFromStock(); System.out.println("####################################\n"); printDatabaseState(); sleep(); System.out.println("\n######### WITH TRANSACTION #########"); System.out.println("Alice wants 2 extra beers."); System.out.println("Now we can update the 2 collections simultaneously."); System.out.println("The 2 operations only happen when the transaction is committed."); System.out.println("---------------------------------------------------------------------------"); aliceWantsTwoExtraBeersInTransactionThenCommitOrRollback(); sleep(); System.out.println("\n######### WITH TRANSACTION #########"); System.out.println("Alice wants 2 extra beers."); System.out.println("This time we do not have enough beers in stock so the transaction will rollback."); System.out.println("---------------------------------------------------------------------------"); aliceWantsTwoExtraBeersInTransactionThenCommitOrRollback(); client.close(); } private void aliceWantsTwoExtraBeersInTransactionThenCommitOrRollback() { ClientSession session = client.startSession(); try { session.startTransaction(TransactionOptions.builder().writeConcern(WriteConcern.MAJORITY).build()); aliceWantsTwoExtraBeers(session); sleep(); removingBeerFromStock(session); session.commitTransaction(); } catch (MongoCommandException e) { session.abortTransaction(); System.out.println("####### ROLLBACK TRANSACTION #######"); } finally { session.close(); System.out.println("####################################\n"); printDatabaseState(); } } private void removingBeersFromStock() { System.out.println("Trying to update beer stock : -2 beers."); try { productCollection.updateOne(filterId, stockUpdate); } catch (MongoCommandException e) { System.out.println("##### MongoCommandException #####"); System.out.println("##### STOCK CANNOT BE NEGATIVE #####"); throw e; } } private void removingBeerFromStock(ClientSession session) { System.out.println("Trying to update beer stock : -2 beers."); try { productCollection.updateOne(session, filterId, stockUpdate); } catch (MongoCommandException e) { System.out.println("##### MongoCommandException #####"); System.out.println("##### STOCK CANNOT BE NEGATIVE #####"); throw e; } } private void aliceWantsTwoBeers() { System.out.println("Alice adds 2 beers in her cart."); cartCollection.insertOne(new Cart("Alice", Collections.singletonList(new Cart.Item(BEER_ID, 2, BEER_PRICE)))); } private void aliceWantsTwoExtraBeers(ClientSession session) { System.out.println("Updating Alice cart : adding 2 beers."); cartCollection.updateOne(session, and(filterAlice, matchBeer), incrementBeers); } private void insertProductBeer() { productCollection.insertOne(new Product(BEER_ID, 5, BEER_PRICE)); } private void clearCollections() { productCollection.deleteMany(new BsonDocument()); cartCollection.deleteMany(new BsonDocument()); } private void printDatabaseState() { System.out.println("Database state:"); printProducts(productCollection.find().into(new ArrayList<>())); printCarts(cartCollection.find().into(new ArrayList<>())); System.out.println(); } private void printProducts(List<Product> products) { products.forEach(System.out::println); } private void printCarts(List<Cart> carts) { if (carts.isEmpty()) System.out.println("No carts..."); else carts.forEach(System.out::println); } private void sleep() { System.out.println("Sleeping 3 seconds..."); try { Thread.sleep(3000); } catch (InterruptedException e) { System.err.println("Oups..."); e.printStackTrace(); } } } Here is the console of the Change Stream : $ ./change-streams.sh Watching test.cart Watching test.product Timestamp{value=6570052721557110786, seconds=1529709604, inc=2} => Cart{id='Alice', items=[Item{productId=beer, quantity=2, price=3}]} Timestamp{value=6570052734442012673, seconds=1529709607, inc=1} => Product{id='beer', stock=3, price=3} Timestamp{value=6570052764506783745, seconds=1529709614, inc=1} => Product{id='beer', stock=1, price=3} Timestamp{value=6570052764506783745, seconds=1529709614, inc=1} => Cart{id='Alice', items=[Item{productId=beer, quantity=4, price=3}]} As you can see here, we only get four operations because the two last operations were never committed to the database, and therefore the change stream has nothing to show. You can also note that the two first cluster times are different because we did not use a transaction for the two first operations, and the two last operations share the same cluster time because we used the new MongoDB 4.0 multi-document transaction system, and thus they are atomic. Here is the console of the Transaction java process that sum up everything I said earlier. $ ./transactions.sh Database state: Product{id='beer', stock=5, price=3} No carts... ######### NO TRANSACTION ######### Alice wants 2 beers. We have to create a cart in the 'cart' collection and update the stock in the 'product' collection. The 2 actions are correlated but can not be executed on the same cluster time. Any error blocking one operation could result in stock error or a sale of beer that we can’t fulfill as we have no stock. --------------------------------------------------------------------------- Alice adds 2 beers in her cart. Sleeping 3 seconds... Trying to update beer stock : -2 beers. #################################### Database state: Product{id='beer', stock=3, price=3} Cart{id='Alice', items=[Item{productId=beer, quantity=2, price=3}]} Sleeping 3 seconds... ######### WITH TRANSACTION ######### Alice wants 2 extra beers. Now we can update the 2 collections simultaneously. The 2 operations only happen when the transaction is committed. --------------------------------------------------------------------------- Updating Alice cart : adding 2 beers. Sleeping 3 seconds... Trying to update beer stock : -2 beers. #################################### Database state: Product{id='beer', stock=1, price=3} Cart{id='Alice', items=[Item{productId=beer, quantity=4, price=3}]} Sleeping 3 seconds... ######### WITH TRANSACTION ######### Alice wants 2 extra beers. This time we do not have enough beers in stock so the transaction will rollback. --------------------------------------------------------------------------- Updating Alice cart : adding 2 beers. Sleeping 3 seconds... Trying to update beer stock : -2 beers. ##### MongoCommandException ##### ##### STOCK CANNOT BE NEGATIVE ##### ####### ROLLBACK TRANSACTION ####### #################################### Database state: Product{id='beer', stock=1, price=3} Cart{id='Alice', items=[Item{productId=beer, quantity=4, price=3}]} Next Steps Thanks for taking the time to read my post - I hope you found it useful and interesting. As a reminder, all the code is available on this Github repository for you to experiment. If you are looking for a very simple way to get started with MongoDB, you can do that in just 5 clicks on our MongoDB Atlas database service in the cloud. Also, multi-document ACID transactions is not the only new feature in MongoDB 4.0, so feel free to take a look at our free course on MongoDB University M040: New Features and Tools in MongoDB 4.0 and our guide to what’s new in MongoDB 4.0 where you can learn more about native type conversions, new visualization and analytics tools, and Kubernetes integration.

August 14, 2018
Next →

Data and the European Landscape: 3 Trends for 2022

The past two years have brought massive changes for IT leaders: large and complex cloud migrations; unprecedented numbers of people suddenly working, shopping and learning from home; and a burst in demand for digital-first experiences. Like everyone else, we are hoping that 2022 isn’t so disruptive (fingers crossed!), our customer conversations in Europe do lead us to believe the new year will bring new business priorities. We’re already noticing changes in conversations around vendor lock-in, thanks to the Digital Markets Act, a new enthusiasm for combining operational and analytical data to drive new insights faster, and a more strategic embrace of sustainability. Here’s how we see these trends playing out in 2022. Digital markets act draws new attention to cloud vendor lock-in in Europe We’ve heard plenty about the European Commission’s Digital Markets Act , which, in the name of ensuring fair and open digital markets, would place new restrictions on companies that are deemed to be digital “gatekeepers” in the region. That discussion will be nothing compared to the vigorous debate we expect once the EU begins the very tricky political business of determining exactly which companies will fall under the act. If the EU sets the bar for revenues, users, and market size high enough, it’s possible that the regulation will end up affecting only Facebook, Amazon, Google, Apple, and Microsoft. But a European group representing 2,500 CIOs and almost 700 organizations is now pushing to have the regulation encompass more software companies. Their main concern centers around “distorted competition” in cloud infrastructure services and a worry that companies are being locked into one cloud vendor. A trend that will likely increase in 2022 that pushes back on cloud vendor lock-in is embracing multi-cloud strategies. We should expect to see more organisations in the region pursuing multi-cloud environments as a means to improve business continuity and agility whilst being able to access best of breed services from each cloud provider. As we have always said …”it’s fine to date your cloud provider….but don’t ever marry them.” The convergence of operational and analytical data The processing of operational and analytical data is almost always contained in different data systems, each tuned to that use case and managed by separate teams. But because that data lives in separate places, it’s almost impossible for organisations to generate insights and automate actions in real time, against live data. We believe 2022 is the year we’ll see a critical mass of companies in the region make significant progress toward a convergence of their operational and analytical data. We’re already starting to see some of the principles of microservices in operational applications, such as domain ownership, be applied to analytics as well. We’re hearing about this from so many of our customers locally, who are looking at MongoDB as an application data platform that allows them to perform queries across both real-time and historical data, using a unified platform and a single query API. This results in the applications they are building becoming more intelligent and contextual to their users, while avoiding dependencies on centralized analytics teams that otherwise slow down how quickly new, data-driven experiences can be released. Sustainability drives local strategic IT choice Technology always has some environmental cost. Sometimes that’s obvious — such as the energy needs and emissions associated with Bitcoin mining. More often, though, the environmental costs are well hidden. The European Green Deal commits the European Union to reducing emissions by 55% by 2030, with a focus on sustainable industry. With the U.N. Climate Change Conference (COP26) recently completed in Glasgow, and coming off the hottest European summer on record, climate issues have become top of mind. That means our customers are increasingly looking to make their technical operations more sustainable — including in their choice of cloud provider and data centers. According to research from IDC , more than 20% of CxOs say that sustainability is now important in selecting a strategic cloud service provider, and some 29% of CxOs are including sustainability into their RFPs for cloud services. Most interesting, 26% say they are willing to switch to providers with better sustainability credentials. Historically, it’s been difficult to make a switch like that. That’s part of the reason we built MongoDB Atlas — to give our customers the flexibility to run in any region , with any of the three largest cloud providers, and to make it easy to switch between them, and even to run a single database cluster across them. Publicly available information about the footprint of individual regions and even single data centers will make it simpler for companies to make informed decisions. Already, at least one cloud platform has added indicators to regions with the lowest carbon footprint. Source: IDC, European Customers Engage Services Providers at All Stages of Their Cloud Journey, IDC Survey Spotlight, Doc #EUR248484021, Dec 2021

December 21, 2021