Decide where the purchase logic runs

The purchase consists of a stock check, a stock change, an order record, and a commit. We have described the required behavior. Where should the instructions that coordinate those steps run?

An embedded engine is a library loaded into the application’s process. A process is a running program with resources managed by the operating system. A database server is a separate running program that accepts requests. It may be on the same machine or another one.

Trace the same operation across a boundary

Suppose the application sends three sequential requests and must wait for each reply before constructing the next. For this illustrative comparison, each round trip across the boundary takes 4 ms, excluding the database’s useful work.

Three dependent requests
Request → reply
Request → reply
Request → reply
Boundary time: 12 ms

One request containing the operation
Request → execute the steps together → reply
Boundary time: 4 ms

Combining the conversation removes two waits in this model. It does not remove the work or durability requirements inside the operation.

A stored procedure is database-side code that can perform several steps after one invocation. An embedded call can avoid a network conversation altogether. Either choice can reduce communication, but they change deployment and failure boundaries too.

If a procedure holds transaction resources while doing slow external work, moving it into the database can make contention worse. Contention means operations compete for something they cannot safely use at the same time. Later concurrency lessons will show this explicitly.

Keep the correctness promise fixed

Comparing a durable committed purchase with a function that merely updates memory would not be a fair placement comparison. The two implementations must preserve the same stock rule and handle the same declared failures.

An embedded library shares the application’s process failure boundary. A separate server can isolate some failures, but requires a communication and authorization interface. Neither arrangement automatically supplies backups, resource limits, or safe upgrades.

The smallest useful engine can begin as a library with a narrow API. A server interface can be added when independent clients and process separation are requirements. Distribution is not a prerequisite for explaining local storage.

Remove the wrong wait

Suppose 90 ms of a 100 ms request is spent waiting for durable storage, while boundary crossings account for 10 ms. If we eliminate all boundary time, can the request finish in 10 ms?

Keep the remaining dependency

No. Under the stated additive model, 90 ms remains. Reducing communication does not eliminate the storage wait. If a measurement reports a much larger gain, inspect whether the durability contract or other work changed too.

We have separated placement from guarantees. The next stage starts implementing the guarantee that a purchase is recovered as one outcome after interruption.

SQLite’s serverless explanation describes embedding; PostgreSQL’s architecture tutorial describes a client/server organization.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter