A real-world puzzle exercise: comparing 2 views of the same events
Gregg Woodcock
We had one source of transactional data that fend into a provisioning system which logged what it saw and then sent provisioning commands to another system which logged what it did. Each system maintained its own DB and these DBs were sometimes out of sync and we naturally suspected that the provisioning system had some bugs. Given the following details, write a search to show us users who were probably not handled correctly:
For each data source (X and Y), the following possible logged transactions can happen for any user (a user's ID is his phone number, "MDN"):
AFA (Add Feature A)
AFB (Add Feature B)
DFA (Drop Feature A)
DFB (Drop Feature B)
MDN (Change MDN)
AUA (Activate User w/ Feature A) <- This is a USER-wide activation (implies XAUB, too, but you will only get 1 or the other).
AUB (Activate User w/ Feature B) <- This is a USER-wide activation (implies XAUA, too, but you will only get 1 or the other).
DUA (Deactivate User w/ Feature A) <- This is a USER-wide deactivation (implies XDUB, too, but you will only get 1 or the other).
DUB (Deactivate User w/ Feature B) <- This is a USER-wide deactivation (implies XDUA, too, but you will only get 1 or the other).
SUA (Suspend User w/ Feature A) <- This is a USER-wide suspension (implies XSUB, too, but you will only get 1 or the other).
SUB (Suspend User w/ Feature B) <- This is a USER-wide suspension (implies XSUA, too, but you will only get 1 or the other).
UUA (Unsuspend User w/ Feature A) <- This is a USER-wide unsuspension (implies XUUB, too, but you will only get 1 or the other).
UUB (Unsuspend User w/ Feature B) <- This is a USER-wide unsuspension (implies XUUA, too, but you will only get 1 or the other).
Obviously, when sorting through this, we need to cancel out any transaction that happens in both systems and only look at the singles on either side.
But it is not that simple. These systems are somewhat smart and try not to do "silly things". This consists of 2 kinds of optimizations as follows.
If events arrive duplicated (10 Activations for Feature A in quick succession), either system may absorb all the duplicates and only log one of them.
Each system is to some extent smart enough to do some internal cancellations and not take any action (not log), but this does not happen every time because sometimes the cancelling events are too far apart in time. Here are some *POSSIBLE* pairs of events that cancel out inside a single system:
Add then Drop
Drop then Add
Activate then Deactivate
Deactivate then Activate
Suspend then Unsuspend
Unsuspend then Suspend
So if we add an "X" for system X and a "Y" for system Y to each of the event types (e.g. XAFA), write a search that can detect events that logged in one system but did not log in the other system that takes into account all the cancellation rules for events.