If you're going to be processing millions of large documents in a batch operation, then you really need the power that a server side software suite gives you.
The server is not going to be able to process a document unless its "on the server" (in memory or whatever). Any service that you invoke (using watch folder, web service, REST, etc.) is going to need the document as a parameter. Given the size of the documents, the server will most likley also need to write the file to a temporary store while they are being processed.
If, however these millions of documents are coming from millions of sources, then you may want to look at a client based/distrubuted solution. If that is the case, then LiveCycle may not be the best solution for you.
thanks for your response! a few additional questions:
1) how, generally, would one go about using the server to manipulate a pdf in the way that i need to (ie. add, modify, delete parts of the pdf, and then save as v1.4 a/1-b? specifically, what services/methods in the api?
2) i have found in some forums issues surrounding the processing of very large pdf's in livecycle. are there known size limitations? are these limitations remediable?
3) what product(s) does adobe offer, other than livecycle, for manipulating existing pdf's in the way i need to in a batch environment?
1 - Add, modify, delete pages and save as PDF/A. This would be done by the Assembler module using the invokeDDX API. A DDX file is an XML file that provides commands as to how you want to add/modify/delete the document.
2 - LiveCycle can handle large documents, but the environment in which it is running may need to be tuned. Service time-outs, JVM memory settings, disk/database sizing and J2EE system configuration will need to be taken into account.
3 - Adobe's product for manipulating batches of documents as you describe is LiveCycle.