I don't really why it is understandable that ongoing requests aren't matched in real time. Conceptually, it seems pretty straightforward. There could be an intermediary data base of ongoing requests that inventory releases get queried against prior to being thrown out into the general exchange population. Granted, batch matching procedures are efficient, but I don't understand how real-time matching would bog down the system.
I have some experience with computer systems built in corporate environments. Limitations such as this generally has nothing to do with compute power.
First, the real limitation is that good computer programmers are very expensive. The best and the very good computer programmers are employed by high tech firms in Silicon Valley, internet startup firms, large financial institutions who pay high bonuses, and large corporations that have high job security and nice benefits.
It is difficult for small and medium size firms (such as Interval) to either pay for such IT talent or to even convince them to join their companies. Moreover, given the expense of computer programmers, an IT department at a medium size firm will be relatively modest in size. The IT department will need to not just employ programmers but also hardware and database specialists as well. Plus the IT department have to not only build the externally facing system (such as the Interval website) but also service their internal IT systems and infrastructure (such as their telephone systems, corporate network, financial accounting system, etc).
Second, given that there is a fixed number of computer programmers at Interval, their time and the features they build need to be carefully prioritized by the business managers. And the features that the business managers will tell their tech staff to focus on will be the features that generate revenue for Interval. Features such as eplus. Also prioritized will be high priority requests from Interval's major clients such as Marriott and Starwood. Other priorities will come from Interval's own service department because their agents need alot of system functionality to be able to look up issues that people are calling in about and then to be able to fix them.
Third, as soon as a computer system is built, it becomes legacy. Servers, databases, networks, and computer code has to be upgraded constantly. The matching system on Interval's website may have been built 15 years ago as a batch process when the cost of compute power and memory was very expensive. At some point, they will upgrade the matching process to be real-time and instantaneous but the question is when will they do that when they have so many other priorities to juggle.
Bottom line is that since TUG has people who are obsessed at maximizing their exchanges on Interval, we can clearly see that the OGS is not instantaneous and this causes us angst. But if you look at it from an Interval corporate perspective, they are looking to maximize their limited system development capability by ensuring they correctly prioritize across all their needs, 95% of which we can never even see since we can only see issues which are evident with their website. But from Interval's perspective, I bet that they think that the matching process works fairly well and the only complaints they get are from a small minority here on TUG.
This is also why we see quirks and bugs on Interval's website. Writing computer code can be complex and so their programmers make small mistakes that make it into their public website and it sometimes takes a long time for them to get around to fixing it.
This is my opinion only and I have no idea what happens within Interval. But hopefully, this can provide some insight into the complexity of what Interval is likely dealing with.
