Scaling the Cloud: Overcoming Infrastructure Hurdles in MedReach-AI (Sprint 2 Retrospective)

As we wrap up Sprint 2 of the MedReach-AI capstone, our primary goal was to connect our React frontend to the FastAPI backend and breathe life into our Analytics Dashboard. We wanted to take raw, sanitized Healthcare Professional (HCP) data and turn it into actionable, real-time insights—visualizing geographic coverage, specialty distributions, and data quality trends. What we actually got was a masterclass in cloud infrastructure scaling, memory limits, and network resilience. Here is a look at the technical hurdles our engineering team conquered this week to stabilize our production pipeline. Hurdle 1: Bypassing Firebase Proxy Limits Our first roadblock hit during the data ingestion phase. We initially routed our frontend requests through Firebase Hosting, but quickly discovered that Firebase enforces a strict 60-second timeout on proxy requests. For massive CSV uploads requiring intensive backend validation, 60 seconds simply wasn't enough. Our solution was to refactor our API client to bypass the proxy entirely, routing large production requests directly to our Google Cloud Run service URL while preserving our Firebase Bearer authentication and dynamic company scoping. Hurdle 2: The Out-of-Memory (OOM) Crash With the network path cleared, we pushed a stress-test dataset of 30,000 records through the system. The result? A 500 Internal Server Error. Because MedReach-AI utilizes a heavy, CPU-bound NLP model (spaCy) for PII scrubbing and data standardization before writing to Firestore, processing 30,000 rows at once caused our Cloud Run container to hit its default memory limit and forcefully shut down. We solved this by scaling our container hardware—upgrading to 8GiB of RAM and extending the request timeout ceiling to a full 60 minutes, giving the AI the runway it needed to process the batch. _Caption: Firebase console displaying the successfully populated records subcollection after resolving the Cloud Run Out of Memory (OOM) crashes by chunking the database writes. _ Hurdle 3: Firestore gRPC Stream Timeouts The data finally made it into the database, but when the Analytics Dashboard tried to read it back, it triggered a 504 Stream removed error. The backend was attempting to download all 30,000 records in one continuous stream, causing Google's gRPC network to drop the connection. Caption: Cloud Run logs showing the container successfully stabilizing and traffic shifting after deploying the paginated Firestore read operations. To ensure complete fault tolerance, we overhauled our FastAPI read operations. We engineered paginated Firestore queries using limit and start_after cursors. By fetching the data in batches of 1,000 records at a time and aggregating them safely in server memory, we completely eliminated the dropped connections. Caption: The finalized Analytics Dashboard successfully fetching and rendering the 30,000-record dataset in production without 504 timeouts. Looking Ahead: Sprint 3 With the data pipeline officially locked down, the Analytics Dashboard is now rendering beautifully in production. As we transition into Sprint 3, our focus shifts from core engineering to project packaging. We will be producing our commercial spot, finalizing our executive presentation, and preparing to defend the MedReach-AI architecture in our final capstone review.