I'm developing a system to handle sending transactional emails to our customers. This is how it works: An event occurs during the order's life cycle, for example 'shipped' This event will trigger the creation of an email in the database (email queue) A separate windows service is polling the db table for new emails to send. When it finds one it calls a Web service with all the required data. It's the Web service's responsibility to handle the actual sending of the email. My question relates to step 2. When an email triggering event occurs, should I take a snapshot of all the data required by the service (thereby duplicating data and introducing new tables) or should I get the required data from the transactional db tables only at the point where I'm ready to call the Web service.[Note: I'm not at all concerned with the body of the email, all I'm doing is passing the data to a Web service. The email templates etc are handled by another system. My concern is purely to queue the email notification and pass the required data to the Web service.]
Data persistence for transactional customer emails
c#;sql server;design decisions
In this case I would serilize the objects needed to pass to the web service and store them in the database. The two services should operate as independently from one another as they can. Serialization of the complete driving objects will allow you to update and adjust the mailer without having to update and adjust the event listener. You could also create a data containing class and pass just the information you need, but then you make 3 updates where there only needs to be one down the line. However, it seems like your building a very complex system, that shouldn't be. Assuming that you need to call the web service to send an email, then why not just  call the web service in the event listener.  If you need to store something to the database, then you can do that too, in the event listener. 