Engineering costs money, so open-ended statements like:

run with as little hardware as possible

...are too incomplete to be stories. Running on as little hardware as possible would be the task that never ends. It may very well be the operator's goal to run on as little hardware as possible, but that is probably a local optimization. If the infrastructure manager has your team spend $2 million of engineering effort to reduce their hardware costs for this application from $40k/year to $10k/year, said manager is going to get handed a box for their belongings and escorted out. You need numbers. You need a spike.

If you have load tests or metrics showing you can run X number of concurrent users on Y amount of hardware, and Y hardware costs Z dollars/year to run, then you can run some experiments. You might decide to stub out enough of your program that you can send controlled amounts of data during your transmissions, and run some load tests. How much do you need to reduce the data size by in order to get a worthwhile reduction in hardware? If you need a 90% reduction in data size to get rid of one node in the cluster, is that even worth doing? Is that even possible to do? Or maybe a 10% reduction in data size will translate to needing 10 fewer nodes in your cluster, and that might save $20k/year in your environment. Once you have information on what's possible and what kind of benefits you might get out of it, you can make an actual story. Something like this:

As a backend operator

 

I want to serve x concurrent users on y hardware

 

So that I can reduce hardware costs by z

Now you have a story that tells us who wants this change, when the change is done, and what the value of the change is. The product owner should be able to decide whether or not this story is worth spending their money on, and what the priority should be. Maybe the lower operational costs will allow the product to be priced more competitively. Maybe hardware is cheaper than losing customers, so the product owner prioritizes a large customer's feature request ahead of this performance optimization task.

The point is, if you have actual numbers to work with, the product owner will know what they are gaining/losing if you do/don't ship this story. Without some rough numbers though, whatever story we come up will be meaningless, and therefore not really a story. Whoever is pushing for this work to get done needs to have at least a little bit of data and experimentation in order to turn those into a story.

Engineering costs money, so open-ended statements like:

run with as little hardware as possible

...are too incomplete to be stories. Running on as little hardware as possible would be the task that never ends. It may very well be the operator's goal to run on as little hardware as possible, but that is probably a local optimization. If the infrastructure manager has your team spend $2 million of engineering effort to reduce their hardware costs for this application from $40k/year to $10k/year, said manager is going to get handed a box for their belongings and escorted out. You need numbers. You need a spike.

If you have load tests or metrics showing you can run X number of concurrent users on Y amount of hardware, and Y hardware costs Z dollars/year to run, then you can run some experiments. You might decide to stub out enough of your program that you can send controlled amounts of data during your transmissions, and run some load tests. How much do you need to reduce the data size by in order to get a worthwhile reduction in hardware? If you need a 90% reduction in data size to get rid of one node in the cluster, is that even worth doing? Is that even possible to do? Or maybe a 10% reduction in data size will translate to needing 10 fewer nodes in your cluster, and that might save $20k/year in your environment. Once you have information on what's possible and what kind of benefits you might get out of it, you can make an actual story. Something like this:

As a backend operator

I want to serve x concurrent users on y hardware

So that I can reduce hardware costs by z

Now you have a story that tells us who wants this change, when the change is done, and what the value of the change is. The product owner should be able to decide whether or not this story is worth spending their money on, and what the priority should be. Maybe the lower operational costs will allow the product to be priced more competitively. Maybe hardware is cheaper than losing customers, so the product owner prioritizes a large customer's feature request ahead of this performance optimization task.

The point is, if you have actual numbers to work with, the product owner will know what they are gaining/losing if you do/don't ship this story. Without some rough numbers though, whatever story we come up will be meaningless, and therefore not really a story. Whoever is pushing for this work to get done needs to have at least a little bit of data and experimentation in order to turn those into a story.