Question: We are currently using transactional replication in SQL Server 2008 to keep a secondary reporting server synchronized with a primary database server. This has been working weel and keeps some of the load off the primary server. Would it be possible to scale this solution to multiple reporting servers? We're expecting an increased load of read-only queries and it would be nice to be able to add reporting servers as needed.

The general idea was the following:

1. Each reporting server would use a "pull" subscription to get the data from the primary database publication. These reporting databases could be a couple of minutes behind the primary server without it being an issue.
2. The reporting servers would be NLB'd together. All read-only queries would be directed to the NLB which should spread the load across the servers.

Answer: 
Sounds like it would work, to me. As long as you're only doing queries to the NLB name. However, I would take a long deep look into the MS SQL deployment and architecture documentation to see if there's anything that says "build it this way, taking care that you do X and don't do Y" or "It won't work at all because of Frob."
The usual bottleneck is the distributor. Make sure you do not have the publisher act as its own distributor, with many ('unlimited') scaling the subscribers load on the distributor becomes quite significant. One solution is to stage the distribution, have one of the subscribers (or more) act as a publisher/distributor too. This way more subscribers can be added as subscribers to this second-hand publication without adding further load on the original distributor.

But given the caching capabilities of Reporting Services and extensive built-in capabilities for scale out (see [Planning for Scale-Out Deployment](http://technet.microsoft.com/en-us/library/bb630407.aspx)), one has to wonder whether such a replication topology is truly needed.