# New project architecture review — RFC

I have drafted three proposed backend architectures for our new services and would appreciate a critical review before we commit to one. Each approach has significant trade-offs that affect long-term maintenance, scalability, and team velocity. I need honest feedback on which path minimizes technical debt while supporting the projected load of ~50k concurrent users.

A few thoughts on the proposed data flow:

• The event bus pattern at this scale will become a bottleneck during peak writes unless you shard by tenant ID upfront.
• Postgres as the primary store is fine, but your write paths are going to fight with the read replicas under load — consider using a dedicated command/query split rather than relying on replication lag tolerances.
• The lambda functions add operational surface area that may not be justified for this service's complexity budget; could these be handled by background workers in the main app?

I'm less worried about the tech stack and more concerned about how you plan to observe failures across the distributed boundary when things go wrong at 3 AM.

Looks solid.