# Maintaining Background Processes Overview

Each new background processes require the creation of two new classes: a `BatchJob` and a `ThreadWorker`. These classes fit into the master-worker pattern used by the background process runtime infrastructure to overcome the throughput limitations encountered by single-threaded processes. By splitting work among many concurrent threads, often on multiple physical nodes, background processes can achieve excellent scalability and react to changing work demands without additional programming. In this pattern:

- A `BatchJob` is responsible for determining the work to be processed for a batch run and then splitting that work into pieces that each `ThreadWorker` will process. When running a single process, a single `BatchJob` object is instantiated by the framework. The framework then makes calls to the `BatchJob` instance at the appropriate time. One such set of calls to the `BatchJob` instance is to return to the framework a collection of `ThreadWork` instances that will be distributed for execution.
- A `ThreadWorker` is responsible for processing a single `ThreadWork` instance for a run. Within the `ThreadWork`, there are many `WorkUnits` representing the fine-grained units of work to be processed. In many cases, these `WorkUnits` represent a complete database transaction. For example, a bill being created for an account, whether or not the `ThreadWorker` executes on the same computer as other `ThreadWorkers`, or the `BatchJob` that created its work is left as a configuration choice to be made at runtime. Within a single process, there may be many `ThreadWorker` objects. In general, each `ThreadWorker` instantiated in a batch run has a corresponding row in the Batch Instance table. The Batch Instance rows provide persistent state that is needed for the `ThreadWorkers` to operate correctly in failure/restart situations.

Parent topic: Maintaining Background Processes