Maybe I am just dumb but I really cannot see how data synch could solve what (in my kind of business) is a real problem.
Example: you develop a web app to book for flights online.
My browser points to it and I login.
Should synchronization start right now? Before I even input my departure point and date?
Ok, no. I write NYC -> BER, and a dep date.
Should I start synching now?
Let's say I do. Is this really more efficient than querying a webservice?
Ok, now all data are synched. Even potentially the ones for business class, even if I just need economy.
You kniw, I could always change my mind later. Or find out that on the day I need to travel no economy seats are available anymore.
Whatever. I have all the inventory data that I need. Raw.
Guess what? As a LH frequent flyer I get special treatment in terms of price. Not just for LH, but most Business Alliance airlines.
This logic is usually on the server, because airlines want maximum creativity and flexibility in handling inventory.
Should we just synch data and make the offer selection algorithm run on the webserver instead?
Let's say it does not matter... I have somehow in front of me all the options for my trip. So I call my wife to confirm she agrees with my choice. I explain her the alternatives... this takes 5 minutes.
In this period, 367 other people are buying/cancelling trips to Europe. So I either see my selection constantly change (yay! Synchronization!!!) or I press confirm, and if my choice is gine I get a warning message and I repeat my query.
Now add two elements:
- airlines prefer not to show real numbers of available seats - they will usually send you a single digit from 1 to 9 or a "*" to mean "10 or more".
So just symching raw data and let the combinatorial engine work in the browser is not a very good idea.
Also, I see the pontential to easily mount DDOS attacks if every client is constantly being synchronized by copying high contention tables in RT.
Your use case doesn’t benefit from your own data. There’s nothing you can do that doesn’t require a direct interaction from the server.
I write an audio recording app, and in my app, users have most to gain from their own data. For most people, syncing is basically an afterthought. In this use case, the ability of having your recordings in your phone is the most important thing.
The difference here lies that in my app, the user generates all the valuable data themselves. In your app, nothing valuable can happen without communication with the airline.
But then the post claims that "everything is a synchronization problem" seems should be qualified better.
Also, most of the comments before mine seemed to be in full agreement that yeah, full synchronization would be a silver bullet, even for cache invalidation
there's certainly things to sync in a airline app. Syncing the current schedules of flight is better than saying no flights exist when offline.
But when you're talking a about purchasing whats basically a live interaction with a paid for service, it runs into the verification/authentication aspect which can't be trusted by random customers.
So yeah, there's definitely apps that sync is a rare bit of concern to the customer/user experience.
Example: you develop a web app to book for flights online.
My browser points to it and I login. Should synchronization start right now? Before I even input my departure point and date?
Ok, no. I write NYC -> BER, and a dep date.
Should I start synching now?
Let's say I do. Is this really more efficient than querying a webservice?
Ok, now all data are synched. Even potentially the ones for business class, even if I just need economy.
You kniw, I could always change my mind later. Or find out that on the day I need to travel no economy seats are available anymore.
Whatever. I have all the inventory data that I need. Raw.
Guess what? As a LH frequent flyer I get special treatment in terms of price. Not just for LH, but most Business Alliance airlines.
This logic is usually on the server, because airlines want maximum creativity and flexibility in handling inventory.
Should we just synch data and make the offer selection algorithm run on the webserver instead?
Let's say it does not matter... I have somehow in front of me all the options for my trip. So I call my wife to confirm she agrees with my choice. I explain her the alternatives... this takes 5 minutes.
In this period, 367 other people are buying/cancelling trips to Europe. So I either see my selection constantly change (yay! Synchronization!!!) or I press confirm, and if my choice is gine I get a warning message and I repeat my query.
Now add two elements: - airlines prefer not to show real numbers of available seats - they will usually send you a single digit from 1 to 9 or a "*" to mean "10 or more".
So just symching raw data and let the combinatorial engine work in the browser is not a very good idea.
Also, I see the pontential to easily mount DDOS attacks if every client is constantly being synchronized by copying high contention tables in RT.
What am I missing here?