Temporal Internals on Random Tech Excursions

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1: Public API and Service Routing #

Welcome! Before we dive into Temporal, imagine walking into a busy restaurant. There is a host at the door, waiters moving around, and a kitchen in the back. You don’t walk into the kitchen and start cooking. Instead, you tell the host what you want, and the host directs you to the right place. In Temporal, that host is the Public API.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 2: Durable Persistence #

In Chapter 1: Public API and Service Routing, we walked through the front door of Temporal. We learned how requests are routed to different services. But a front door is not enough. What if the server loses power in the middle of a workflow? If everything lives in memory, it’s gone. That’s why Temporal has durable persistence.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3: Task Queues and Matching #

In Chapter 2: Durable Persistence, we learned that Temporal writes every important workflow event into durable storage. That’s how workflows survive crashes. But a ledger can’t do work. A workflow must run code: charge a credit card, ship a package, send an email. Temporal needs a way to connect work that needs doing to a worker that can do it. That’s where task queues and matching come in.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4: Visibility and Search #

In Chapter 3: Task Queues and Matching, we saw how workflows get their work done through workers. But think about this: what if you have thousands of workflows running at the same time? How do you find the one that belongs to customer Alice? Or how do you find all workflows that are stuck on a payment problem?

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 5: Archival and Object Storage #

In Chapter 4: Visibility and Search, you learned how to find workflows by querying metadata. You can locate a workflow, but what happens when that workflow finishes? Does Temporal keep every workflow history in its main database forever? If it did, the database would eventually become huge, slow, and expensive.

Think about a busy office. Your team uses nice filing cabinets for current paperwork. But every closed project also goes into the same cabinet. After a few years, the cabinet is overflowing. You can barely find anything, and the office rent is too expensive for storing old paper.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6: Observability and Telemetry #

In Chapter 5: Archival and Object Storage, we saw how old workflow histories can be moved to cheap object storage. That keeps the primary database fast. But now imagine you are the person who runs the Temporal server. The server is processing thousands of workflows. Is it healthy? Is it slow? Is a worker broken? You need a way to see what is happening inside the server.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 7: Cluster Membership and Internal RPC #

In Chapter 6: Observability and Telemetry, we learned how to monitor a Temporal server and see what is happening inside it. But so far, we have talked about Temporal as if it were a single server. In real life, Temporal runs as a cluster of multiple nodes. That raises a big question: when there are many nodes, how do they agree on who owns which workflows? And how do they talk to each other?

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8: Application Composition and Lifecycle #

In Chapter 7: Cluster Membership and Internal RPC, we saw how many Temporal nodes work together as a cluster. Now let’s zoom out one level further and ask a bigger question: How is the whole Temporal server application put together?

The server is not one giant main() function. It is built from many pieces: frontend, history, matching, persistence, visibility, and more. Someone has to wire these pieces together in the right order. Someone also has to start them and stop them without causing errors.