BigDecimal for Money: Precision, Scale and Domain Rules

Why this problem matters

Financial values need decimal semantics, predictable rounding and auditable rules. A double represents many decimal fractions only approximately, so arithmetic can produce values such as 0.30000000000000004. The deeper issue is not only precision: money also has currency-specific scale, rounding and validation rules.

A useful mental model

BigDecimal stores an unscaled integer and a scale. The numeric value 12.30 has unscaled value 1230 and scale 2. Equality is scale-sensitive, while compareTo compares numeric value. That distinction matters in tests, persistence and domain invariants.

Design principles

The following principles are useful because each one creates a boundary that can be reviewed, tested and observed. They are not independent checkboxes: together they define the behavior of the system under normal load and partial failure.

How to validate: Verify the assumption with stress tests, thread dumps, Java Flight Recorder data and repeatable runtime measurements rather than relying on a single successful local run.

Key trade-offs

Good engineering makes the cost of a choice visible. For this topic, the most important trade-offs are:

Concrete example

The example below is intentionally small. Its purpose is to expose the control point or data flow that the design depends on, not to present a complete framework implementation.

BigDecimal amount = new BigDecimal("12.30");
BigDecimal tax = amount.multiply(new BigDecimal("0.0825"))
    .setScale(2, RoundingMode.HALF_UP);

record Money(BigDecimal amount, Currency currency) {}

When applying this pattern, define what happens immediately before and after every durable boundary. That is where duplicate work, stale state, lock duration, timeout overlap or deployment risk usually enters the design.

Common failure modes

Failure modes are more useful than generic “best practices” because they describe the condition the design must survive. Review each one as a concrete test scenario.

• new BigDecimal(0.1) captures the binary approximation. The usual consequence is hidden backlog, duplicate work or state that can no longer be explained. Add a bounded guardrail and reproduce the condition under load.
• Division without a rounding rule throws ArithmeticException for non-terminating decimals. This often passes unit tests because the timing, cardinality or dependency behavior is too clean. Test it with realistic concurrency and an intentionally slow or failing dependency.
• Mixing currencies in one numeric column without a currency code. During restart or replay, the defect can turn a recoverable incident into inconsistent state. Preserve enough context to detect, stop and safely resume the workflow.
• Using equals in tests when 10.0 and 10.00 should be treated as the same amount. The safest mitigation is to make the assumption explicit in a constraint, deadline, queue limit or state transition, then alert when the boundary is approached.

What to measure

Production behavior should be visible before a failure becomes a customer complaint. Metrics should connect a technical symptom to a workload, business state or recovery objective.

• Rounding adjustments by transaction typeUse this as an early saturation signal and define what healthy, warning and overloaded behavior look like.
• Rejected values with excessive scaleBreak this down by service version, endpoint, partition or tenant so aggregate averages do not hide one failing path.
• Currency mismatchesCorrelate this with user-visible latency and error rate to distinguish harmless internal work from customer impact.
• Reconciliation differences by minor unitTrack both the level and the age of the condition; an old small backlog can be more serious than a brief large spike.
• Database precision and scale violationsReview this after deployments and failure drills so the dashboard proves recovery, not only steady-state health.

Interview-ready explanation

A strong explanation starts with the invariant: state what must remain true even when requests repeat, dependencies slow down or instances restart. Then describe the mechanism that preserves it, the failure mode that mechanism introduces and the signal that proves it is working.

For BigDecimal for Money: Precision, Scale and Domain Rules, avoid listing tools first. Explain the workload and boundary, walk through the normal path, introduce one realistic failure and show how the system recovers. Finish with the metric or test that validates the claim. That structure demonstrates senior engineering judgment more clearly than naming patterns without context.

Review checklist

Use this checklist during design review, implementation planning or incident follow-up:

1. Use string or minor-unit construction.
2. Store currency explicitly.
3. Define scale and rounding per operation.
4. Validate database precision.
5. Test boundary and reconciliation cases.

A sound design is not the one with the most patterns. It is the one whose invariants, limits and recovery paths are explicit—and can be demonstrated.