SQLite *

Imagine a client submitting an order. The server inserts the row and commits the transaction. Just before the response reaches the client, the connection disappears. The client sees an error. The database contains a perfectly good order.

What should the client do now?

Retrying is reasonable from its point of view. The client cannot see the commit. But if the server treats the retry as a new operation, there are now two orders. This failure has nothing to do with a slow database or a broken transaction. The transaction did exactly what it was supposed to do. The ambiguity sits between the commit and the response.

I wanted to make that gap visible in a small program. It uses SQLite as a stand-in for the order database and deliberately raises a connection error immediately after committing. There is no HTTP server in the program; the returned status codes represent the responses an API would send. This keeps the experiment focused on the database state and the client's uncertainty.

We describe the implementation of a custom Domain Name System (DNS) by using C socket programming for network communication, together with SQLite3 database for the storage of Internet Protocol (IP) for Uniform Resource Locator (URL). Then we provide a performance analysis of our implementation. Our code is available publicly [1].