Scalability

Vertical scaling increases the capacity of an existing machine, for example by increasing CPU and memory. It is conceptually simple and often requires fewer application changes because the system still runs on one larger host. Its limits are the maximum capacity of the machine, cost and the fact that the machine remains a failure dependency. Vertical scaling can be a sensible first response when the workload and operational model are still simple.

Horizontal scaling adds more instances and distributes work among them. A load balancer can route requests to App 1, App 2 and App 3, and more instances can be added as capacity needs rise. It can improve capacity incrementally and reduce dependence on one application server. The trade-off is additional infrastructure and distributed-system complexity, including shared state, connection budgets, deployment coordination and failure handling.

An application instance is stateless when it does not depend on its local memory for important user state that must be available to another instance. If a session exists only in App 1's RAM, a later request routed to App 2 may not find it. Persisting appropriate shared state in a database, Redis or an external session store allows application instances to remain interchangeable. Statelessness does not mean the entire system stores no state; it means state is not trapped in an individual application process.

Adding application instances can increase the number of concurrent database requests. The database may become constrained before the application layer. The supplied scalability notes list indexing, query optimisation, connection pooling, caching, read replicas, partitioning and sharding as possible techniques. They should be introduced based on measured bottlenecks and query patterns rather than automatically.

An index can help PostgreSQL locate rows that match common filters without scanning the entire table. For example, a query filtering tasks by project_id may benefit from an index on that column. A composite index on (project_id, status) may help a common query that filters by both values; index order and usefulness must be checked against actual query plans. Connection pooling reuses a bounded set of database connections instead of continuously opening new ones for every request. Pool limits must be sized with the database's total connection capacity in mind.

Read replicas can serve selected read traffic while the primary database handles writes. Replication lag means a replica may not immediately show a recent write, so read-after-write behaviour must be considered. Partitioning divides a large table into smaller physical partitions and can help with large datasets and lifecycle management. Sharding distributes data across multiple database nodes; it adds routing, operational and cross-shard query complexity. These are later-stage strategies, not default optimisations for every project.

For the Task Management API, start with stateless Spring Boot instances, a load balancer, PostgreSQL connection pooling and appropriately designed queries. Add indexes based on observed query patterns. Use Redis for repeated reads that have a clear freshness and invalidation policy. Only consider replicas, partitioning or sharding when measurements show that simpler techniques are insufficient. This staged approach keeps complexity proportional to the workload.