Container memory cap and connection pool saturation in horizontal replicas

Investigate how Railway's horizontal scaling of service replicas interacts with per-service connection pool constraints under increasing internal traffic, given that container-level CPU and memory limits are enforced as hard caps to prevent single-service exhaustion of project-shared resources.

Internal networking relies on private DNS names for inter-service communication; however, the platform's behavior regarding per-replica connection pool allocation and traffic distribution across scaled instances remains unspecified.

Does Railway assign a dedicated connection pool to each replica, or do replicas share a project-level pool abstraction?

How does the platform handle connection pool exhaustion when a single replica exceeds its container resource limit during burst traffic?

Are connection pool size parameters adjustable per scaled replica, or are they governed by a project-wide default?