Discloud Container vs External Services for Bot State

Discloud's shared container architecture suspends idle applications on lower tiers, making cold start latency a common source of perceived slowness rather than intrinsic code performance. Before optimizing bot logic, it is necessary to distinguish whether delays originate from container suspension cycles, Discord gateway heartbeat timeouts, or resource throttling within the container boundary. A central unresolved decision involves whether to retain databases, caches, and queues inside the Discloud container or relocate them to external services, given the platform's design constraints against persistent data workloads. This architectural choice directly affects deployment readiness time, gateway ACK reliability, and the scalability profile of the bot across restart events.

Under what thresholds does container-local state trigger unintended suspensions? How does external database latency compound gateway heartbeat timeouts? Which metrics reliably signal that a bot has outgrown Discloud's container-bound state?