Modelling lifecycles, time, money and rules interview questions

Read a monotonic clock to measure how long something takes: timeouts, waits between retries, rate limits and latency figures. It only moves forward and its starting point means nothing, so only the difference between two readings is useful, and it is never shown to anyone. Read the wall clock when you need a moment that means something outside the program: when an order was placed, whether a hold has passed its deadline, which day a sale belongs to. Store those moments as UTC instants and convert them to a time zone only for display and for rules about local days. Never measure a duration by subtracting two wall-clock readings, because the wall clock can jump. In a design, put both readings behind one injected clock so that tests control them.

A double stores fractions in binary, as sums of halves, quarters, eighths and so on, so most amounts of paise or cents, 0.10 included, are kept as the nearest binary value rather than exactly. The error in each value is tiny, but it shows up exactly where money cannot tolerate it: 0.1 + 0.2 is 0.30000000000000004, so totals that should be equal compare unequal, and long sums drift. Keep whole minor units in an integer instead, such as 1999 paise for 19.99 rupees, or use a decimal type such as Python's Decimal or Java's BigDecimal, and keep the currency with the amount. Then rounding happens only where a business rule says, with a mode the code names, instead of wherever the hardware happens to round.

Choose version 7 for keys that a database indexes, such as order or event IDs. It starts with the creation time in milliseconds, so new IDs sort after old ones and inserts land at one end of the index instead of all over it, and any process can still make one without asking anyone, as with version 4. Choose version 4 when an ID must not reveal anything: a version 7 tells everyone who sees it when it was made, which is wrong for an ID that must hide when an account was opened. Use neither as a secret. RFC 9562 says UUIDs should not be assumed hard to guess and must not be used as security capabilities, so a code that opens something comes from a secure random generator, with limits and an expiry of its own.

Because consecutive versions can then share a boundary without overlapping or leaving a gap. The old version ends at the instant the new one starts, and that instant belongs only to the new one, so every moment has exactly one version in force, and the check at load time is simple: sorted by start, each version must begin exactly where the previous one ends. With inclusive ends, either both versions claim the boundary, or the end is written one second or one day earlier, which leaves a gap below that unit. Half-open periods also add up: a year split into months counts no instant twice. Store the boundaries as instants, in UTC or with their offset, so that a change at local midnight is one moment for every server.