Skip to content

Jaggies Weekly

The Twelve-Factor App: Concurrency

Dev, Architecture pattern, The Twelve-Factor App, English1 min read

Scale out via the process model


Web applications have various process execution forms. PHP, for example, processes function as child processes of Apache, starting based on request volume, while Java processes operate within a massive JVM uberprocess, managing concurrency internally through threads. These running processes are minimally visible to app developers. In the context of the twelve-factor app, processes are crucial and they are a first-class citizen, drawing inspiration from the unix process model for service daemons. This model allows developers to allocate different workloads to specific process types, such as handling HTTP requests through web processes and long-running tasks through worker processes.

Moreover, while individual processes can handle internal multiplexing via threads or asynchronous/event-driven models, vertical scaling of an individual VM has limitations. The process model excels in scaling out, as the share-nothing, horizontally partitionable nature of twelve-factor app processes facilitates simple and reliable addition of concurrency.

Furthermore, the text emphasizes that twelve-factor app processes should refrain from daemonizing or writing PID files. Instead, reliance on the operating system’s process manager (like systemd or cloud platform-based distributed process managers) or tools such as Foreman during development is encouraged. These tools effectively manage output streams, handle crashed processes and address user-initiated restarts and shutdowns.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit the site for more detailed explanations. That's all folks!