The speaker introduces the topic of backward compatibility, followed by a definition and explanation of the concept. He illustrates the importance of maintaining backward compatibility by discussing its impact on system updates and user experience. Krish then shares a personal experience with a product encountering a backward compatibility issue after an acquisition or migration, highlighting the challenges and implications for users. Finally, he explores potential strategies for addressing backward compatibility issues, such as ID mapping and dynamic checks during user requests, while emphasizing the significance of thorough testing to prevent such issues from affecting end-users.
Summary
Definition and Explanation of Backward Compatibility:
- Krish defines backward compatibility as the property of a system that allows it to be interoperable with legacy systems.
- He provides examples and explains the importance of maintaining backward compatibility to avoid disrupting the user experience during system updates.
Example of Backward Compatibility Issue:
- Krish shares a personal experience with a product encountering a backward compatibility issue.
- He describes how changes in message IDs after an acquisition or migration led to archived messages reappearing unexpectedly.
- Krish discusses the implications of such issues for users and the challenges in resolving them.
Strategies for Addressing Backward Compatibility:
- Krish explores potential solutions to the backward compatibility issue, including ID mapping, dynamic checks during user requests, and data migration.
- He evaluates the pros and cons of each approach and reflects on why the product he uses may not have addressed the issue.
- Krish emphasizes the importance of thorough testing to prevent backward compatibility issues from affecting end-users.
Podcast
Check out on Spotify.
Transcript
0:01
Hey everyone, this is Krish and welcome to Snowpal Podcast. In this podcast, we'll talk a little bit about backwards compatibility.But before we go into the podcast, I want to ask you if you're a teacher or a tutor. If you haven't already done so, and you can check out a service that we have that's specifically targeted at you, I'm pretty sure you're going to enjoy the productivity that it brings to you.
0:28
OK, having said that, let's get into the podcast backwards compatibility.What is it?It's essentially the property of a system that allows for it to be interoperable with the legacy system, right?So that's, I guess a loose definition, if I may.
0:46
But what it essentially means, if you don't remember the definition, then here is what it means.Let's say you have an application that has a particular feature and over a period of time you've made some changes.Let's say you're making a set of changes and by virtue of those changes, the existing system right.
1:06
The existing users would be impacted if not for you doing something more.What that more means could be one of many things, but what it essentially means is that you don't want to disrupt your existing system or the the user experience of your existing user base when you make these newer changes.
1:26
That's easier said than done.Let's take one or two examples and see what that means. So one of the products I use an online platform, they I mean.Again, it's it's guesses and a lot of speculation here, but it's based on experience as well.
1:45
So not all of this might be entirely untrue in my opinion.What I'm trying to say is, one of those products that I use I ran into a problem with with a certain feature that they had.I archived a number of messages that were sent to me over a long period of time, but one day they suddenly all started showing up and I was like, wow, that seems a little weird And I thought, OK, probably it's just a random bug.
2:11
And then I tried to archive the message again. It disappeared, except that when I went back to the page, it showed up one more time and you know, it got me curious and I was like, OK, what what could I possibly change?You know, they've apparently underwent, as I understand by reading the news, they were purchased by another company or there was some acquisition or whatnot.
2:32
But Long story short, I could tell that the messages that were sent to me recently since that acquisition or something of that nature had a different ID, right?The ID was, I know whatever number of characters, but it was, it had a different length, it was alphanumeric.
2:48
It looked different than the messages in the past that I had a different ID. So I figured, OK, you know what, it must be backwards compatibility issue.Now they probably were required.They went through some migration and some things fell through the cracks and maybe they noticed this, maybe they did not.
3:08
I reported an issue, but it never got fixed. So maybe it is not at the top of that list.Maybe there aren't that many people who have these messages from years hanging around, or maybe it doesn't bother them.I like to keep my inboxes clean, whether it's my e-mail inbox or message inbox and other products that I use, so I can tell when something like this happens.
3:31
But you know, if you're the kind of person who doesn't necessarily triage these messages because you like them the way they are, you may or may not have noticed that particular problem, that bug any case, right?So the previous messages had a different ID, different length, different looking ID than the newer ones.
3:51
So here's my speculation, right. So let's say the ID was a 123 in the past and then you archive that message, you know it got persisted.There was a flag that was set to true. So the next time the messages were pulled up, it did not show those messages.
4:08
It's pretty simple right now after the acquisition happened, probably, right, or some sort of a migration happened, it may or may not have anything to do with that acquisition or the merger or whatever it was regardless, right?That's besides the point.
4:24
The IDs changed because they moved to a different system.Maybe they changed their persistent layers, maybe they integrated a bunch of different layers, and maybe they made some other code changes, right?So the IDs were different.If that were to be the case, what could they have possibly done right that isn't a bad example of taking, you know?
4:41
It isn't a bad example in the context of discussing backwards compatibility, so there are many options.Obviously one of them is you try to map these IDs. So if my ID is a 123 and if my new system is B, starts with a B.
4:57
It's a stupid example, but I hopefully it conveys the message.If the new system uses a prefix that starts with the letter B as opposed to A, then what you could do is essentially port over all, migrate all your existing messages, change the A's to the B's, then you're in good shape, right?
5:14
So the new messages that get created obviously get created with the B as with B as a prefix.The old ones end up getting migrated and then everyone's happy.That's one solution, maybe not the most optimal one, and probably not a viable one either in in many cases.
5:31
Because what if your system has millions of users, right?Hundreds of millions of users or or 10s of millions or maybe hundreds of thousands, Doesn't matter. It's still a a a tedious process. And there's just one example.There could be other types, other things that you have to do as part of this migration.
5:46
So maybe not a great idea, right?And what is the point in taking that approach either even if you don't have that many users because you're going to go through this exercise of doing the migration.I mean, there are pros and cons.You're going to go through the exercise, it's going to take a long period of time, which I guess is all right because you're doing it.
6:03
It's not, it's not online OLTP transaction processing, right. So it's happening behind the scenes through a Cron job at different times. So nobody's really impacted, right.There's no down times and nobody's affected as on a per user basis. So that's OK.But still, you're doing a large number of updates which may I may not add any particular value.
6:22
The other option you could take is not do anything at all.And then when the user actually goes in and you pulls up the list of messages and now you're going to go get the list of messages that you have to show to that particular user.You could do one extra thing.You find all the unarchived messages going by the rules of your new system.
6:43
In addition to that, you can also account for the delta, which is hey, my old system had these IDs starting with the letter A as an apple, but the new one starts in B as in boy. So if I find messages that start in A, then I'm going to not show them unless they're not archived, right?
7:03
So we do this extra check.And what that means is when you pull up these messages, you could do those checks and then you're only probably only showing N number of messages at any given time. So you're not showing like thousands of messages, right?So you're probably going to show 20 or 30 or 50 and then the user scrolls or goes to the next page depending on your product, and then you go get the next set of messages.
7:25
So you could do this. So it's not terribly expensive.This way you avoided the migration, the cost of migration, and you're doing it when the user is making the request.The only downside is you're doing one extra thing every time when the user makes the request as opposed to the migration which takes care of it once and for all.
7:43
But that apart, this approach should would generally work now you could go on step beyond now every time the user get request the list of messages.You don't have to go through this process of checking to see whether it's an old message or a new one or yada yada yada, right.The first time you pick up an old message and you make this determination, you could replace that with a newer Ida unique ID that's a sequence number or something that's generated, or whatever it is, you can replace that with a new ID and set the flag accordingly.
8:15
So from then onwards, from that point onwards, you don't have to do that extra check for those messages that have already been dealt with, right?So we've talked about three different ways of solving almost the same problem.Unfortunately, the product that I'm using, they didn't get to resolving it.
8:32
So even today I do see my old archive messages from years ago. It's a little bit of a pain.Maybe it's not their priority, so they didn't get it fixed, but maybe their system's more complex.Maybe maybe they have to do more things to resolving this issue, so it is not something that they want to deal with.
8:50
But regardless, at least this gives you some example for.Again, maybe in this case you may or may not entirely have to worry about backwards compatibility.Those are messages if it impacts messages from like years ago.But there are other scenarios that could be a whole lot more pressing and you couldn't not do take care of this, either via migration or via the next time the OR the via the first time the user makes that request after you've gone through the migration process.
9:17
So migrations can get trickier.You want to make sure you do enough testing so you catch all of these before your end user spots these problems.That was helpful.Thank you.
Top comments (0)