The last presentation of today's of really great learnings in the business track. I want to say it's been great to be here. I appreciate those who have made it. We are certainly not giving the least of the presentations, but it is today's last about companies who've been working with MongoDB and their life cycles to transform their business. We've heard from those who are just starting from scratch, those who've been in production a few years, some who've taken years to make their journey, and some who've done it in two months or less. I'm going to recap all the statistics at the end of this presentation that I've learned from the 15 presentations we've got, so it's worth hanging tight. But for now, turn off your mobile phone sound. Make sure that you fill in the survey when you're done. We're going to hear about Hike Messenger, a brand new company in India who's created a really cool, interesting, and compelling social messaging system. We have the pleasure of having Mr. Rajat Bansal here to share that story with us. He's the CTO of the company. He comes with many years in the IT industry with many positions in that field, specifically at Microsoft, Adobe, and some others like Amazon. And he started up this company nine months ago. Hike Messenger.
No, 15 months ago.
15 months ago. Nine months it took to get 15 million customers. That's the story. Really glad he's here. Thank you for bearing with us. Rajat, thank you so much for your time.
[APPLAUSE]
Thank you. Thanks for making through this presentation. Last one is not a good slot to be in. I've learned it. So what we'll cover is, why this product is there? We got a lot of questions around why do you need another messenger. So we'll cover that part there. Then we'll cover the part of, why as a startup we chose MongoDB and how has that helped us as we have grown over the years. Over the last 15 months, not years. And then we'll do a deep dive into some of the typical Mongo use cases that we have been able to achieve, and what have been the learnings throughout the journey.
So the first question that usually comes to us is, what is Hike? So to sum up in one line, what I'll say is it's the fastest growing made-in-India IM App. Then I make a mention of all 50 million users. I'm please to announce that last week we actually had 20 million as well. So we want another 5 million in three months again. And as I speak here, actually, we have on-boarded a very massive ad campaign back home, and we are hoping to grow multiple times over the next few months.
So basic question that comes is, why is there a need for another app? We have too many of those message apps with deeper pockets, bigger bank balances, large number of users which are way more than what we are currently having. So the question was, do we actually need another app? Is that a market for that? Is there a user segment for that?
So when we started this journey, what we said was, like-- what we've figured out were unique challenges which are very specific to the locale which we are operating, and that was India. We also saw what was successful in the past in terms of if we see Line in Japan or WeChat in China or Kik in Korea. There were very, very business-specific players that were doing something very specific for the region. And India, just by sheer volume, was a billion-users opportunity like that.
So what we looked at was some of the unique challenges in terms of low smartphone penetration. So in the market was still not too many smartphones. Although the number of devices were huge, the number of smartphones themselves were very low.
A lot of users were coming on to the net for the first time on mobile. So they haven't seen mobile on desktop or graduating from other sources. So for them, the first experience with the net was on mobile itself. How do we engage or how do we improve that experience? That was the thought behind it.
Similarly, rather expensive mobile internet. Operators still charge something like three [INAUDIBLE], which is roughly $0.05 an MB. Which is huge. In today's world, the cost of that data is huge. So how do we optimize for that? And those were like very, very specific local challenges which may not be solved by other apps that are there in the system.
Similarly, diverse cultures and communication. Too many different languages, the way people communicate. So how do we solve that sort of thing?
Large youth population. A significantly, significantly large youth population, and that's the audience we have decided, OK, that's our switch point, because that's the audience which is growing very, very fast. So all this and a very price-sensitive market.
So what we analyzed was these things-- that there is a market, and that market is changing fairly fast. I talked about things like smartphone. In 2014 estimate is that we'll have 18 billion new smartphones in India, which is roughly 186% growth year over year. That's a tremendous, tremendous growth there. And teens are in the youth segment, what we were targeting. It's 22% of that market but growing at a rate of 600% year over year.
And seeing this data and the potential in terms of how big the market is, right from roughly 405 million unique customers. 800-- plus 800 million plus connected SIMs. It was a huge risk potential there. Currently, the number of messaging users altogether might be around 100 million there. So there's still a big gap and a big opportunity because of all of the connect problems.
As I talked about, unique challenges for India and unique solutions. So I'll discuss few of them before jumping in how we choose them and what are the technology there. Low smartphone penetration and low network conditions. We came up with an Always Connected kind of offering there, where we are seeing that even if you're not all online or you are not on data. Still you're connected to the group or the persons you're checking with, and you can automatically switch to SMS mode there.
So to give people a case of that experience, we actually funded SMS. As you use the product more, you will get more of the SMS. So you're always connected whether you are on data or not. And that's, again, a very unique offering there. That helped us solve a problem, which existed in that region, grant us more users.
Similarly, lack of privacy. And this is not just local, but, I'll say, Boston. Sitting in that local market in terms of everybody's on WhatsApp-- parents, spouses, wife, girlfriend. And not only that. Then there are people who are serving you a newspaper who are serving you milk, or everyone has boarded the applications there. You might not want that divulge your last-seen or your privacy options in terms of profile pics to everyone there. Privacy was a big concern. The question that teen was asking was, why the heck everyone can see your last-seen? Something like-- this was like a teen that looked like there.
So what we came out was with the concept of that, as a user, you choose who sees your last-seen time. It's up to you. It's your data. It's your privacy data. You choose whom your profile picture be delivered to. So we came up with the concept of Favorites. So you have a phone book of 1,000 people, but you can mark five-plus favorites. And only those five people will actually receive your thing-- that when were you last seen. If you change your profile pic, they always get updates of your profile pic. This again, targeted towards youth, got us our next set of users, a very big set of users there.
Then the third problem was for spying. It's again, people get a hold of your phone, first thing is now WhatsApp or something else. How do we protect my data then? We came up with something called Hidden Chats. So you have a list of chats of 50 groups where two of those chats might be very, very sacred to you. Those kind of business chats in terms of your financial numbers or personal chats with a special someone.
So we came up with an option where we can just mark some chats as hidden. And now till that time, you actually enter a pattern, you will not see those chat. As soon as the application goes in the background, anything happens, those chats are again hidden. So we took privacy concept to the next level, as well. It's not about just privacy. Protect your data as well.
And similarly, there are lots and lots of most region-specific features that we learned from the market and we said that this is what we'll build up. So how has been our journey so far in terms of Hike Journey? We launched in December 2012. So we chose a date of 12/12/12 as to launch Hike Messenger there.
First four months during the half months and up to 2013, we hit the $5 million mark. We had 5 million users. And that's when we got our first round of funding as well, which was $7 million, funded by two of the biggest telecom players, Bharti from India and SoftBank from Japan.
There were multiple milestones in between. The next big milestone we announced was on 19 Feb 2013, where we hit the actual 50 million users. And with that came the next round of funding, which was $14 million for us. And last week, there were actually 20 million hikers. So the growth part for us has been exponential. It's like a J curve, but I'll say that the incline is still to come.
So coming back to the part of of why did we choose MongoDB? So as a startup, we were a three-people team when we were writing our service was back in 2012. And in database, where we saved our storage, the units are governed by CAP theorem. CAP is consistency, availability, and partition tolerance. But that's what our technical presentation there. On the business side, none of them are true. For us, the business decisions were governed by cost, by availability of talent, and production support with a community base or interface base.
For us, it was extremely important that we can start small and then grow big as and when we want to. On the cost front, start small. We started with a very, very small implementation. One replica set with two instances hosted on this too. A few hundred reads/writes per second we were happy. But I talked about four months we were reaching that 5 million mark fairly, fairly fast.
As we are doing this, as we saw the growth, we launched into a mode of multiple replica sets. We said that, OK, we'll go will Provisioned IOPS. I'll share in one of the learning slides. It's not always what seems fast. It's not an issue there. So if our first landing spots, like MongoDB, was returning it slow, whereas now finally figured out the IOPS byte was not good enough.
So we were touching those thousand operations per second in the first couple of months of operation excel. And then came the big blast, which was 5 million users, where we grew even bigger, multiple applications, sharded clusters. And recently, last month, as we were preparing for the next round of growth, we moved to SSD instances as well.
Currently, what we are touching is roughly 5K operations on our charts there, and we have actually just did 23 operations in production there. So at any given point in time, as a technology honor, I make sure that all my systems are scaled, at least five times if not more.
So basic concepts which have helped me out optimize cost was, start small, grow big, and grow big fast. So all this happened in a period of three months, where we were able to start with a very, very small-- in one instance, few hundred reads/writes to 5K reads/writes happening over a sharded cluster there. And yes, cost was a concern there. Cost was the concern, and that was one of the fees in the CAP part of the thing.
Then came the availability of connector. As I talked about, a very, very, small team-- three-people team starting- and lighting the entire server. And when I say server, Mongo was one part of it. There was had a lot of messaging server that we created around and could treat as a protocol. Then we have some of these instances-- JMS queues.
The entire sever was nothing but all written by three people. No DevOps, no admin guy. The developers have to be the administrators of the server as well. And the developers simply loved it. It's easy to ramp up, easy to use, multitasking. They just loved it. And this is what I'll say, that like, this is how developers go. When you say OK, you have to choose MongoDB, they're like-
And other important part was how do you keep your services running in production? So I'll say that the third part of the puzzle was actually the production support there. In terms of being not the first into that market, the cost of downtime is significantly higher volume. Because once you lose their trust, your users are gone. Like four rounds of downtime? You have an issue there.
So cost of downtime was really, really high. the reactive situations needed help. If now with a team of four people who are managing everything-- something was wrong, they need help where it's possible. And that's where our interface support came in. So we were one of the earlier adopters of interface support back in March 2013. Only we were a four-people team, very small service hiccups, but we went for interface support there. And to me, that they actually helped. Helped when we needed it most there, because in reactive situations, that came to the rescue.
What MongoDB also give us as in the interface support was proactive health checks. Matt here is one of the people who worked very closely with us. Visits our office, and we do a proactive health check to say that, OK, what are the things that I should be fine-tuning when, instead of 50, I'll be reading 75 million users. What are my next bottlenecks that can be there? And that has helped us really avoid a lot of situations. So instead of being reactive and screaming around that time, we have been proactive and been able to scale very, very much on that front.
How we are using MongoDB? So one of the things that we use is for offline message store. So as a messaging app, we never store your messages. So what we store is your messages just a transit. So if I'm sending a message with someone and that guys is not online. So I'll hold on to that message for some time till the time that that person comes online. And if he doesn't come online within a certain period, the message will expire. So we'll never, never, never store messages.
But for that duration, there are lots and lots of documents coming to the system. There are hundreds of millions of documents that go through the system every day. So it's not a very large, persistent store, but the rate at which the information changes in that store was fairly, fairly high.
This is the store where we tested up to 30K operations, which was a mix of 15K reads and 15K writes per second on our current implementation. And it's horizontally scalable, so I can grow it to 10 times, 20 times, 30 times where I want to. And with what I saw through the morning in terms of document level locking, I think we have no need to grow this one. There's a big Mongo there.
Then what we did was we did an [INAUDIBLE] by saying that we actually built an in-memory differentiation in readers to say where I need to query Mongo or not. So when I say 5K queries, actually there was supposedly 15K queries that should have gone to Mongo. But 10K I was able to avoid by storing it whether this should go to MongoDB or not.
We got these messages transit, so I'd need to say that whether you'll have a message in Mongo or not So every time I talk to Mongo, I just turn off the written memory to say that next time the [INAUDIBLE] comes online, I need to query MongoDB. And I was able to actually say who turned off my [INAUDIBLE] going to MongoDB just by the simple memory map that we maintained. So this was our little treat to MongoDB there. How are we fairing in terms of mean90 Latencies of less than one millisecond for all the reads that we do. And yes, mean90 is not good, so I thought, OK, what's the upper look like? So upper is the topmost. What we are getting is 12 milliseconds in terms of the query hits on MongoDB there.
The second sort that we use is, it's not a sharded cluster. So this is the replica set of 1 plus 4. We have to use a primary for writes. All reads go to secondary there. We have a separate instance which-- serves at the back end there. Here the document sizes are fairly large, and latencies that we always see is less than 10 milliseconds.
As a messaging app, our aim is for the time the message reaches us from the network to the time which it leaves for the [INAUDIBLE]. The overall time the message spends in the system should be less than 14%. So for us each of the DB queries is very, very-- 10 milliseconds is 1/4 of the time I want to spend a message on the server there. So we keep optimizing for those things.
So, how has been our journey with MongoDB there? So our happy state has been 1 millisecond, less than 1 millisecond. Fluctuates between 0.6 milliseconds to 0.8 milliseconds, depending upon volume, time of the day, et cetera. But all journeys are not that smooth. So this is how the one year timeline looks like. And any guesses on what are these peaks? There are not peaks for us in terms of number of users or if we've got 50 million users on a day. These are actually the learnings that we had as we were scaling up out systems.
So these are learnings where the message latency has actually leapfrogged to 900 times, 50 times. Mongo is not responding. And I'll share some of the insight, like, what these were. Fairly common. Not like-- it's not that-- each one we saw. What we saw was our latencies went over the roof. From that one millisecond have it start to leave, and up to 1,000 milliseconds of queries to start responding there.
What went wrong? So what we did was we launched our very big rewards program to incentivize our users. And we were just holding some information in arrays. And we are incrementally changing that arrays. And perfectly fine. We have been writing to MongoDB a lot more load than what we're doing now.
We reached out to that panic situation, virtual support to say that what's happening around there. This is what we are doing, and we don't understand what's happening around there.
Came to the rescue. Figure out that every time you add or modify, you will update an array. You can actually not to end up modifying just a single entry, but the entire array again. And for us, array is rotating very fast and they were growing really fast. Again, 30 minutes of arrays, we were back up and running. We did it, but we wanted people to understand what the issue was. Fix the issues before the CMD back in business again.
So there the learning was that production support, that panic of situation-- it would have taken us a few hours to actually react to that situation had you been not been on to interface support. As a start-off, we talked with a community service support, but we realized the importance of downtime is fairly, fairly high for us.
Let's look at another issue there. So here, what went wrong? Latencies went up to 20 to 500x. So again, from that millisecond, we were seeing 20 to 500 milliseconds latencies for the query step.
What went wrong? Disk I/O was becoming a part of it. So this was actually, as we were growing and we were getting more and more users, latency started fluctuating. And what we figured out was finally it was not MongoDB that was rendering us slow queries. We were hosted on EC2 with the EBS back instances. And we haven't provisioned enough IOPS on EC2.
Learnings was read the proper connections Disk I/O. So it was not a DB fault. It's just like you need to provision it correctly, give sufficient responses for it to come and work back. We went to the Provision IOPS model, configure the 8,000 [INAUDIBLE] 4,000 IOPS. Back to normal Back to a happy state of 0.652.8 milliseconds.
That make sense? So it's like-- what was I going to say-- is like a nightmare. MongoDB stopped responding. And I believe almost any time in the life cycle would have seen this of some Odex script doing damage to the production time. One new person joining the team was writing a script. He thought of running that script on the production database. That script was doing a full-table scan over an area of our users, altered the system entirely.
Again, it's not there weren't flags to protect our system. MongoDB had a flag to say that Enable No-Table what it Scan- even if you try to do it, it will fail. So protect your system's stuff. That's what the learning there was, to say that-- how do we protect our systems and make it, what I'll say, like developer proof. Yes, developers love it, but the things you love it-- you'll try to a lot more things that. And that's where you end up actually breaking it as well. So it has been a very, very, what I'll say, is like a very good ride for of us with MongoDB, with all the support, the community. Those equal definitely as twice as any startup. So in Pearson's presentation, he's saying that they're Unicorns. Yes, start-ups are Unicorns, and we've come up very, very fast there. There is no baggage to carry upon, but what MongoDB enabled us over last 15, 16 months says, scale up and scale up really, really fast.
To summarize Hike's story, it's like, start small, grow big, and grow really fast. Developers love it. At least if I have to go and sell NoSQL will be like-- I think MongoDB is the easiest one to go and sell it. In terms of tools, in terms of efficiency, in terms of edit queries, it's a lot more developer-friendly tool than maybe a DevOps. So I don't speak for them as of the moment. That was one of the things, but it's a way, way more developer-friendly software.
And our third is production support saves you. So whether it's enterprise support, community support-- depends upon what critically of the DBs you're learning in. I'm highly likely to come in and having some sort of support run on that. Because it's from experience of scaling from zero to 20 million in a very short span of time, that each of those instance-- even one instance, if you can save a few minutes-- that's very, very well worth it. Thank you. You can download the messenger at hike.in. Follow us on [INAUDIBLE]. And we all good there. [APPLAUSE]
How nice to hear a unicorn story at the end. Gives us hope to go out and do it again. Any questions for Rajat? Any questions you want to-- anything? Last thoughts? Yes, we've got one. Right over there. Great. Thanks. A unicorn. Anyone else thinking of being a unicorn business? I mean, what a great way to start. Doesn't it inspire you to do that?
Hi, thanks for the excellent presentation. I thought it was pretty amazing how you all have really identified what are the unique challenges in the Indian market, whether it be low smartphone penetration, the cost and whatnot, free Hikes and stuff. I thought that was pretty cool. I'm just curious. Not that I know too much about the current Indian market, having lived away from India many years, but my sense is that the youth market that you are after is fairly fickle, so to speak. And it's pretty amazing that all you guys keep innovating with really nifty features to keep them engaged and to ensure that do you get to the network effects. But what's your take on this market being that fickle and looking for the next new fresh, shiny thing that they could possibly experiment injunction?
So for us that's the opportunity we are banking on. We are exactly banking on the fact that this is the segment that will move fast. And when we say "fast," fast and fast. So this 20 million is just the very tip of the iceberg there. If I can move the youth to my-- you are saying that people will move from one app to another. I'm saying that if I can be that app, I'm more than happy to take that risk. I should have a product which appeals enough for the youth. And then it's up to me to say that builder product, which engages and keeps the users in the system.
To break the social network is very, very tough. Yes, even if you have 20 friends and 19 people like your product, still that 20th comes to your product. All 19 are not on your product. So to me, what we take, that is an opportunity. That youth is a the segment that are fast to move. And can I be that offering when they move?
You have a question? OK.
So you've been referring to the different offerings that are available for MongoDB. You referred to the health checks that are out front. You referred to the emergency cases when you called the support. With MongoDB, usually urged our customers or encouraged them to use the support even before something happens. So when you're thinking about changing a model, a deployment model, or changing something in your development, have you ever done this before? Have you any experience in that?
Yes. So what we have done is, for us-- I'll again point to Marty. He has been our single point of contact for us for MongoDB. So any time we have queries in terms of something else that we'd like to achieve or we'd like to change the data model in a particular way, or we are unsure whether that will work or not. We do get it, where if I reach out to MongoDB to say that, is it something that can cause issues? And all [INAUDIBLE]. I'll set it as a startup. Three issues in a year, yes. It's a lot. But still, as we were learning, those were pretty-- we were able to prevent a lot of issues because of those proactive.
So what we do is, whenever we have a proactive health check, we'll actually go down. Do our health checks in terms of what the documents are, what the structures are. Are we using the right sized data type to store it? So one thing we observed was we were spooling strings as such, and we could have used digital for a particular data, which would have compressed our DBs there.
So we do look at those opportunities as we are doing health checks there. And then we take back those learnings, spend two months, implement that, all when we get the opportunity to do those things, and then be ready for the next health check as such.
OK. Thanks so much.
Thank you. [APPLAUSE]
OK, for those of you who have been around, I'm just going to tell that the 10 things that I took out of this. We started yesterday with quantum leaps of data across many areas of the world with Citibank. Quantum leaps. They made incredible things. Then we heard a story by IoT and how power tools actually can be safe for us to use. How you can make accountants happy at AHL, because they gave data to their quants 100 times faster at a hugely reduced cost.
We heard-- yeah. So many things. The UK government tell us about how they have created gov.uk. That's been award winning. 2.5 months to create an entire supply chain at the Gap. Sorry, I had these in order. The VAs, the biggest user of NoSQL databases in the world. I don't know where that set came from and if it's true. I just want to remember that.
Sanofi is bringing together clinical and research data to improve our chances at finding cancer. That's an amazing one. Falling in love can happen 95 times faster if you sign up for eHarmony, where they make 438 marriages a day. That's pretty cool.
Medtronic is improving lives and saving lives every three seconds by collecting the data that they do. Weekly releases is common. Can you imagine weekly software releases? Forbes created a new and scalable software package for publishing in two months and they now sell it. So a traditional company actually packaging up software for publishing-- that's pretty amazing out of the back of MongoDB.
And last but not least, a billion students have been through Pearson, with 120 of them active users in a mobile first strategy. And of course we learned just now about 20 million users on a brand new app in 15 months, which is wonderful, because we should all strive to be unicorns. I'm going to put that in something nicer than that. But OK, that's what I heard. Thanks so much for staying with me. [APPLAUSE]