[apple050620312]

Summary

• Add validated SHARD_COUNT and SHARD_IDS configuration for distributed shard workers.
• Move synchronous database operations off the event loop with bounded execution time.
• Add bounded TTL/LRU caches for guild settings, filters, and webhooks.
• Bound link-fix and EmbedEZ concurrency and rate-limit overload warnings.
• Replace analytics row loading with database-side counts and buffered asynchronous event writes.
• Document multi-process shard assignment and capacity-tuning controls.

Priority

P1 — removes event-loop and upstream-service bottlenecks that become critical at roughly 50,000 guilds.

Validation

• Independent shard parsing and bounded-cache smoke checks pass.
• Runtime imports and all Python AST parsing checks pass.

[Kyrela]

Add validated SHARD_COUNT and SHARD_IDS configuration for distributed shard workers.

Is this an actual need? Because the bot can run on almost any device with enough RAM without any distributed architecture, even on an 60k guilds bot

Move synchronous database operations off the event loop with bounded execution time.

Theorically a good idea, but in practise the ORM isn't thread-safe + instead of serving links slowly under heavily loads, this impl simply drops them + it's pretty useless with the cache

Add bounded TTL/LRU caches for guild settings, filters, and webhooks.

Again, theorically a good idea, but you're reinventing the wheel/adding overkill stuff

Bound link-fix and EmbedEZ concurrency and rate-limit overload warnings.

EmbedEZ doesn't really have load-related timeout problems, but It doesn't cost much, so the EmbedEZ part is pretty good. But, the semaphores adds nothing and drops links.

Replace analytics row loading with database-side counts and buffered asynchronous event writes.

count_since is so obvious I wonder why I didn't do it in the first place. The buffered asynchronous event writes is pretty useless rn, but it doesn't cost anything, so it's good too. As said in the first PR tho, I need to get rid of this ORM, and this event table, as there's no reason for this to be a relation database. It should be in a separated, log-oriented database.

Generally speaking, this PR is really overkill and doesn't fit the bot style/ecosystem at all. For example, it skips its config file entierly to use env variables instead.