Need Architecture Advice: Scaling Claude API matching with a growing Bubble database

Need help
1

I am working on an app where I have integrated Claude. The current setup is that I send Claude a list of symptom names along with the user’s input, and Claude returns a list of symptoms that best match the user’s prompt.

The app is used to collect reviews from patients. Patients describe what they were feeling, and we have a database of symptoms. Claude compares the patient’s description with our symptom list and returns the most relevant symptoms. So far, this part is working as expected.

Now I need some advice on the architecture.

The symptom list is not stored in this app. It exists in another Bubble app, and I fetch it through an API. The problem is that the API has a limit of 100 entries per request, while we currently have around 500 symptoms, and that number will continue to grow.

To work around this, I created a table in my current app with a field of type List of Text and stored all 500 symptom names there. I then pass this list directly to Claude. I’m also considering adding an API call from the main app so that whenever a new symptom is created there, it is automatically created in this app as well, keeping both apps in sync.

However, I am highly concerned about several critical problems with this setup as we try to scale:

  1. Claude Tokens and Skyrocketing Costs: Passing a flat list of 500+ symptom names into the prompt every single time a patient submits a review consumes a massive amount of input tokens. As our database grows to 1,000+ items, this is going to become incredibly expensive and highly inefficient.

  2. Accuracy Drop (Attention Dilution): I’m worried about the “needle in a haystack” effect. As the list gets massive, Claude’s accuracy will likely degrade because it is forced to choose from too many options, causing it to miss relevant symptoms altogether.

  3. Frontend Latency (Slower Response Times): Shoving thousands of tokens into Claude’s context window on every call slows down the API processing time. Patients are going to experience a frustrating delay on the frontend waiting for their tags to load.

  4. Bubble Database Performance Bottlenecks: Storing hundreds or thousands of items inside a single List of Text field. Loading that massive list into memory during workflows will eventually slow the app down drastically or hit capacity limits.

How would you suggest I restructure this architecture to make it scalable, efficient? I would love to hear your suggestions on the best way to handle this workflow.

2

Typically you would want to use something like a vector database to do things like this. Not a Bubble database. You can use something like this:

Hope that helps. :blush:

4

Thanks! i will try this

5

What is this slop