This rather implies that the original software was not competently designed.
It has to be remembered that the size of the “current state” data is not big (7-8k docks, 6k bikes, few 100k subscribers) – this is not big, if you remember that the real-time part of the system does not need to know the subscriber’s name and address and so forth.
You’ve basically got a list of live keys;
List of docks, grouped by location
bike is either linked to a dock, or it is linked to a key. Bike may be broken. Dock may be broken.
That’s really all the real time stuff you need – it is very small, even with a million subscribers and 100k bikes/docks
The state-changes (key takes bike out) need to be streamed to an accounting database, but all you need for the operational system is the live “now” state (which would fit in less than a gig of RAM)
and the ability to query it quickly.
Sadly, you are probably right – they won’t chuck it in the bin and start again (although a lot ought to be rescuable from teh existing system – eg terminal UI software).
But I wonder how much money they’ll waste hacking on it and what effective “waste” they’ll be from a system that does not have the confidence of the user.