Q: Understanding network performance impact of 32 bytes per request My company is using redis on a fairly performance critical path. An nginx server calls out to it once per request. The call itself has several arguments, which are currently like 80 bytes. This call goes over the network to redis, which passes the args to a lua script it has loaded and then makes a decision and returns it.
My boss thinks that adding an additional 32 byte string to those arguments is unacceptably bad compared to hardcoding the string in the lua script (which sucks for other reasons), because "if we get 50k requests in a second, that's 1.6GB of additional network traffic in that second." My intuition is that this is not a concern. The traffic is from an EC2 instance to an ElastiCache instance, and I think that because of how packets work, and how small the request already is, those 32 extra bytes are very unlikely to incur significant processing cost in the network stack at either end. Am i totally wrong?

A: Performance
The performance of the entire application could not be affected at all. You can spend significant time doing micro-benchmarking. However because you increase a request in one place, it could have a ripple effect in the entire application. As long you do not increase the number of IP packets, the performance hit could be minimal if network latency is high. The bottom line, benchmark. Leave in the code the option to be able to chose which implementation you will use at runtime (e.g. a toggle option).
Code quality
Usually it is more important to have a good quality of code and have room to expand your application than to limit yourself. You can design later a filter that will minimize, compress, cache etc your traffic towards redis, that will help you gain more speed than a small optimization.
