Middleware Order

Middleware order is a product decision, not just a wiring detail.

A neutral production sequence is:

1. observability
2. concurrency control
3. database or storage session setup
4. idempotency
5. tenant or chat resolution
6. user loading
7. i18n setup
8. incoming message persistence
9. command or feature permissions
10. business rules specific to the bot
11. post-processing side effects

Why this order works:

• observability wraps everything
• idempotency and throttling happen before expensive business logic
• i18n is available before handlers start rendering
• persistence runs before downstream consumers depend on canonical message data
• feature-specific checks happen after core context is already loaded

Use separate middleware stacks for:

• message
• edited_message
• callback_query

Do not assume the same middleware set is correct for all update types.