My temporary-email platform depends on Gmail IMAP to retrieve messages and then serve them through an API. Under real-world traffic (about 1,000 users every minute) three problems show up: new emails take far too long to appear, some messages never reach the API at all, and the whole service can freeze or crash. I do have a rudimentary throttle, but it simply isn’t effective. I need the IMAP layer refactored so that: • Incoming messages are visible to the API in a couple of seconds at most. • The service remains stable and responsive while 1,000 concurrent users poll continuously. • Smarter, Gmail-friendly rate limiting prevents connection bans or resource spikes. You will have access to the existing codebase, logs, and monitoring dashboards. Your deliverable is improved, well-documented code plus a brief load-test report proving the targets above. If your fix involves new libraries, queueing, or connection-pooling solutions, include setup notes so I can reproduce the environment. Hands-on experience with Gmail’s IMAP quirks, connection pooling, async workers, and performance profiling tools is essential. If you have previously scaled a disposable mail or high-QPS email gateway, I’d love to see your approach and results.