Centralizing vs decentralizing of rounding-off and summation of data

Question

Let's say there is a database that persists transaction data , e.g transaction items list of sale invoices , in raw format. Something like this

InvoceId	Item	Price
1	Product-1	2.8592
1	Product-2	10.7559
1	Product-3	5.25

Data is exposed to other backend and frontend services by an API , let's call it API-A. All the UI components need to display rounded-off data with sum in the bottom.

Simplified version of the architecture looks like this:

The question is, should API-A take care of rounding-off and summation of data ? Such as, accepting some query string parameters to support rounding-off and summation. Or should each consumer in this architecture take care of rounding and summation separately ? and why?

Answer 1

Rounding isn't something you can undo. It's a lossy process. So if there is any chance you'll have a need to do the rounding differently (rounding comes in many styles) then do the rounding in the report. Not in the stored data.

Of course that assumes the data can be stored without rounding. Some numbers like π can't be. So when you store them as data (not symbols) you're storing errors as well. When you make those errors part of a calculation it's a good idea to track their potential impact and be sure they don't grow enough to become significant.

One lesson I learned the hard way was if you're going to sum up floats that have different exponents it's a good idea to sort them and add up the the smaller ones first. Otherwise the big ones eat the little ones because their significant bits don't line up.

But hopefully you're not doing anything as silly as representing decimal money with binary floats in the first place.

TL;DR Don't store rounding if you can help it. If you can't, be sure you're using the right kind of rounding for your domain. Make sure the calculations you do on that data can tolerate the error caused by that rounding.