 Hi, I'm Rithikesh. I am a part of the DevOps and Developer Team at Fresh Service, which is part of FreshWorks. For those of you who attended the talk yesterday, you're not going to get anything new, so just bear with me for five minutes. Yeah, so Fresh Service is a cloud-based ITSM product, IT help desk with asset management and ticketing capabilities. So I'll talk about, I'm sure the audience here is aware of encoding, right? What an encoding means? So for UTF-8 is a kind of an encoding for strings, and Fresh Service being a ticketing platform, we had a lot of tickets that were created via multiple channels like email, mobile, et cetera, right? And it was created in 2013, back when emojis weren't so predominantly available or not predominantly used on enterprise software. So we created the app on MySQL database with UTF-8 encoding, assuming that it would support the generic UTF-8, which is four bytes, but apparently it didn't. So MySQL's UTF-8 only supports three bytes of data, whereas the generic UTF-8 usually supports four bytes. MySQL never really admitted it and went ahead with a new version of UTF-8 called UTF-8 Mb4. So if you were running a production app or any app with UTF-8 encoding, you would have to go migrated to UTF-8 Mb4 to support rich content like emojis, et cetera. With our product, we would see some emoji content in the early days, and to work around it, we used an open source gem called GmojiParser, which was by GitHub. What it would do is it would tokenize the rich content from four bytes to three bytes so that it could be stored in the database. So for example, a grinning emoji would be converted into the tokenized format called grinning, colon, grinning, colon, which I think if you use any of the web platforms of, say, Twitter or WhatsApp, if you type this, the emoji actually comes up. So it's actually the textual representation of the actual emoji. And we were okay with this. We were making it work. This was back in the early days, but when we, the emoji, as a, emojis kept evolving, right? Every year you see, or every month you see new emojis coming up. So the open source gem couldn't really keep up with the number of emojis coming up. And every now and then we would see some new emojis that was unsupported in the tokenization format. So we would have broken layouts on the ticket details page where we would have to go manually fix the content because when it was written to the database, it would actually convert it to some junk value before saving. And it was also expensive for every ticket that we were creating or a conversation that we were adding, we were tokenizing the content. To the scale at which we create almost one million conversations a day and process around half a million of emails every day. Also with the growing trends, we would have had to de-tokenize the emoji to represent it as an original emoji, at least in the future, which also would have been expensive, right? So like around last year, Christmas, we upgraded the rails, we run on Ruby on rails. So we upgraded the version of rails and that broke in production the emoji, the MySQL connection actually. So rails connects with MySQL in a strict mode in the newer version of rails. What that made was any content that was not compatible with the database version of the column, it would break, it will throw an exception. So as I mentioned, MySQL's UTF-8 would only allow three bytes, wherein if an unsupported emoji that was not parsed by the tokenizer, it will try to save it as it is in the database and it will throw an exception. So now we had a burning issue where we would lose customer data, the tickets would not get created if there were any unsupported emojis around. So we decided to look at solutions and we had a couple of options, either run the, either migrate the entire MySQL database to UTF-8 and before or go in a more hybrid approach where we migrate, say specific columns or we could also go one step further and only migrate specific, sorry, we could migrate specific tables or go one step further and migrate only specific columns to UTF-8 and before. That allowed us the flexibility of not having to run complex migrations for the entire database. So rails also, you need to specify the encoding at rails level as well as MySQL level. So with rails, we only had to make a small change to set the encoding at UTF-8 and before and we would then go take an incremental approach of migrating the columns. So I'll get done, this is closing the marks. Okay, anyway, we benchmark the solutions and it was more or less the same but after running the incremental migrations we noticed that the performance was actually much better.