Not in any particular order ...
Setting up caching to reduce some request times, especially for data that rarely changes. Updating caches in the background can be helpful.
Addittion of High coverage unit and integration testing
Addition of especially load, stress and volume testing results code optimization
Addition of worker threads
Addition of necessary comments and more solid Documentation
Reuse some code snippetts that indicate similarity
use buiding tools to generate prod level builds
Have migrations that don't syncronize with any entity changes
Move full code to async pattern
Can you think of a way to tackle the problem our users have from another direction or with a different approach?
Influx has an observable query that can be utilized to emit data to any open clients. This would give clients "realtime" data.
I could have a single transmitter in the cold room that can capture multiple data from multiple sensers e.g door-opening-closing sensor etc and have more data for clients.
Have the broker send data directly to MySQL.
Several Options ...
Register the IoT devices in AWS IoT Core. The device sends data to AWS timeseries db. Set up Lambda functions to process/play around with the data. Non IoT data is stored in the AWS RDS.
Set up a cluster (ECS/AKS) and deploy my containerized code (docker) in the cluster nodes. Services will be accessed via the Amazon API Gateway and Route 53 for web services. Non IoT data is stored in the AWS RDS.
Deploy the API in elastic beanstalk. Use cloud provided Influx Cloud Instance for data storage. Serve the frontend as static assets in s3 and cloudfront.