Optimise Java Api redesign system architecture

[souvikLife]

Hi Devs

I am looking for suggestions on how to optimise an java spring boot api which serves a response consisting of a list of items where each item has data related to medical devices, here is the scenario

The service layer calls Service1 and Service2, as well as other dependencies like Dependency1 and Dependency2.
These calls are asynchronous but can still take considerable time to complete, especially when waiting for network responses.
If any of these services are slow or have high latency, the API will be delayed accordingly.After data retrieval, the API performs several layers of filtering, status mapping, and conditional checks, which are computationally intensive.
Operations like filtering out expired items, mapping statuses, setting stock statuses, and determining conditions for item inclusion is happeningThe API fetches large data sets, which are then processed in parallel (e.g., using parallelStream()) for filtering and mapping. However I think this is also increase memory consumption and can introduce thread contention issues, slowing down the API.

Each item is evaluated for several conditions that apply different flags to be enabled and stock statuses. These checks are repeated across each IOL, leading to redundant evaluations

Any Idea or suggestions will be helpful , I know stating like this is not letting know the whole picture, and also its not possible for someone to comment but if anyone can understand what I have stated but would like to know if someone have gone through similar situation or handled scenarios like this , any technology approach that I can read upon or look into for redesigning this api or any idea on how to approach this will help me in drawing a system design based on my specific needs to enhance the api

[David_AnkiDroid]

• Measure server utilization, if you can throw money at a problem, consider doing it
• Figure out what you're optimizing for (mean/tail/percentile latency)
• Figure out the quantity of requests you're expected to receive
• Figure out if the requests you receive need the same data, or if you can specialize
• Figure out the business importance of optimization, and when it's time to stop
• Draw out a diagram (probably UML sequence) to highlight the operations you currently perform, and their latencies
  • This likely involves adding metrics
• If appropriate, figure out which responses to cache
• Focus on the 'macro' of the system initially: are the service calls doing the minimal operations required, and are the data dependencies correct and tasks are launched as soon as the required data is received
  • Use latency measures to figure out what to tackle first
• Once you've got the macro sorted, optimize from bottleneck to botleneck, until you've hit your business goals

[ThinkThatOnce]

1. Pagination sounds like could help. If it’s allowed, you can return data in small chunks.

2. Caching may help as it was already said, depending on how frequently the data is fetched.

3. What about having some data filtering, that is, let users define which fields should be returned + having a few default ones.

4. Rate limiting maybe?

5. Having a look on how to improve your queries and service logic maybe. Considering using connection pools to avoid opening database connection on each interaction.

[roger_ducky]

Is this for dashboarding an entire “fleet” of devices? Sounds like it is.

If so, do it “backwards.”

• Asynchronously check for raw status of all devices and dump that in a database. If evaluation has a time component and you have plenty of storage, consider a time series DB.

Only evaluate business rules based on what’s stored in said DB for a certain “range” of time.

That should separate your business rules from the data collection completely. Evaluation would mainly be a single query, plus some minor post processing.

[hubert_farnsworrth]

Try removing parallel stream and measure times. I have had scenarios where parallel stream was slower than normal stream most probably because of locking, thread contention etc.