Chapter One · What a Backend Is

What a Backend Is

A process that listens on a port, keeps the only copy of the truth, and answers over a network that can lose the answer after the work is done. Five topics name every part of Stagedoor, follow one seat hold through all of them, state the fact the whole book rests on, explain why a four-second render freezes an instance, and draw the line where this book stops and its neighbours begin.

5 topics

The client sends bytes, the service parses them into typed values, decides what is true, writes it down, and answers. Four verbs, and the rest of this book is what goes wrong inside each of them under load. The seat that two buyers were both sold, the checkout that charged one buyer twice, the ticket emails that arrived forty minutes late — every one of those happened inside a service where each line of code was correct on its own.

This chapter is the map. Stagedoor is introduced box by box: two API processes, a worker, a Postgres primary with a replica, a Redis, and a payment provider on somebody else's network. One seat hold is walked through every layer it touches, with the milliseconds attached, so that "the database is slow" stops being the reflex answer. The fact that every later chapter depends on is stated once and slowly: the network can fail between any two lines of your code, and the caller cannot tell a request that never arrived from one that succeeded and lost its answer.

The chapter ends with the three neighbours, the courses on the other side of the line this book draws, so that the reader knows why one Redis stream is taught as a client and Kafka is not taught at all. Marek owns Stagedoor for all fourteen chapters, and three things about it do not make sense yet. They stay unexplained until the machinery exists to explain them properly.

Four verbs, and the chapter that owns each one
Parseat the boundary
Decidein the domain
Persistin Postgres
Answerover the network

Topics in This Chapter