Data Bugs

Multiple identical records are created from a single user action — because the submit button can be clicked more than once before the first response arrives, the API is not idempotent (retrying creates a new record each time), or a background job processes the same message more than once with no deduplication.

After a record is successfully updated, the application continues to display the old value. This happens because the frontend does not re-fetch data after a successful write, a server-side cache is not invalidated on update, or a read replica with replication lag returns the pre-update value immediately after the write.

When a user record is soft-deleted — its deleted_at column is set to a non-null timestamp — it continues to appear in GET /api/users list responses. The database query does not include a WHERE deleted_at IS NULL filter, so soft-deleted records are indistinguishable from active ones in API responses.

A product price entered as 19.99 is stored and returned as 20.0 after being saved through the application. The database column is defined as FLOAT — an IEEE 754 approximate numeric type — rather than DECIMAL or NUMERIC, which are exact types. Because 19.99 cannot be represented exactly in binary floating-point, the stored value differs from the input.

The order-processing message queue uses at-least-once delivery semantics. When a consumer fails to acknowledge a message before the visibility timeout expires — due to slow processing, a crash, or a brief network interruption — the broker redelivers the message. Because the consumer has no idempotency check, the redelivered message is processed a second time, creating a duplicate order record with a different ID but identical contents.