It sounds as a really good ecosystem for drools and jBPM.
Business Processes are usually more high level and you don't really need to care about how they are executed. If you are interested in very low level workflows, you can definitely spawn two different processes into two different threads, that will do the work for you.
I think that one of the important things that you need to do, is to first understand drools and jBPM in depth to be able to define the architecture that fits for your use case. Memory wise, you will need to answer questions like for example: is the JVM able to create 15 objects per second and keep all of them in memory for a week? Answering these kind of questions will help you to decide how to break apart your problem into different subproblems and how drools and jbpm fits into that.
Drools & jBPM has being designed to be flexible enough to work in almost every scenario, so I'm sure that they can help you a great deal into your current project, but you will need to spend some time learning about the projects in order to leverage their benefits.
Earlier I had worked in Telecom domain particularly in OSS where we have built custom Events Processing Engine using java. We had different types of rules(Supression rule, event correlation etc) for processing events and producing alarms. Since I have gone through the development of that engine I see the CEP feature of jBPM+drools is perfect fit which provides you the out of box solution.
But you need to check how does jBPM+drools will scale horizontally and see how you can integrate some in memory caching mechanisms like terracotta cache (not sure whether jBPM+drools can support this) instead of DB persistence