Just as an FYI, I was (and am) exploring a couple of different designs for these model classes.  Initially, I decided to only store the data I cared about in the instance variables.  Over the past couple of weeks, however, this has proved to be a bit lacking because instances of these models are stored inside the Delayed Job table.  As a result, when I wanted to modify the behavior of the job to deal with some additional data I hadn't modeled, I'd have to update this class.  Updating this class would then create a synchronization problem since the class stored in the database is now out of sync with the class defined in code.

The approach I'd like to refactor this to is to store as much data as possible up front, in an easily accessible form.  Ideally the simple de-serialized JSON payload.  Then, the model class could have new methods added to it and the data remains the same which avoids the synchronization problem with the delayed job table.

I only mention all of this so you have an idea of why the model is the way it is and where I plan to take it later.  I think this is fine now.  The data doesn't live for very long in the DJ table anyway, so this isn't much of an issue.  If we were solving a problem that had a much higher frequency or a longer queue, however, this approach would probably be an issue for us.

-Jeff