This post introduces the concept of *durable execution*, which is used by Stripe, Netflix, Coinbase, Snap, and many others to solve a wide range of problems in distributed systems. Then it shows how simple it is to write durable code using Temporal's TypeScript/JavaScript SDK.

# Distributed systems

When building a request-response monolith backed by a single database that supports transactions, we don’t have many distributed systems concerns. We can have simple failure modes and easily maintain accurate state:

- If the client can’t reach the server, the client retries.
- If the client reaches the server, but the server can’t reach the database, the server responds with an error, and the client retries.
- If the server reaches the database, but the transaction fails, the server responds with an error, and the client retries.
- If the transaction succeeds but the server goes down before responding to the client, the client retries until the server is back up, and the transaction fails the second time (assuming the transaction has some check–like an idempotency token–to tell whether the update has already been applied), and the server reports to the client that the action has already been performed.

As soon as we introduce a second place for state to live, whether that’s a service with its own database or an external API, handling failures and maintaining consistency (accuracy across all data stores) gets significantly more complex. For example, if our server has to charge a credit card and also update the database, we can no longer write simple code like:

```js
function handleRequest() {
  paymentAPI.chargeCard()
  database.insertOrder()
  return 200
}
```

If the first step (charging the card) succeeds, but the second step (adding the order to the database) fails, then the system ends up in an inconsistent state; we charged their card, but there’s no record of it in our database. To try to maintain consistency, we might have the second step retry until we can reach the database. However, it’s also possible that the process running our code will fail, in which case we’ll have no knowledge that the first step took place. To fix this, we need to do three things: 

- Persist the order details
- Persist which steps of the program we’ve completed
- Run a worker process that checks the database for incomplete orders and continues with the next step

That, along with persisting retry state and adding timeouts for each step, is a lot of code to write, and it’s easy to miss certain edge cases or failure modes (see [the full, scalable architecture](https://temporal.io/blog/workflow-engine-principles)). We could build things faster and more reliably if we didn’t have to write and debug all that code. And we don’t have to, because we can use durable execution.

# Durable execution

Durable execution systems run our code in a way that persists each step the code takes. If the process or container running the code dies, the code automatically continues running in another process with all state intact, including call stack and local variables. 

Durable execution ensures that the code is executed to completion, no matter how reliable the hardware or how long downstream services are offline. Retries and timeouts are performed automatically, and resources are freed up when the code isn’t doing anything (for example while waiting on a `sleep(‘1 month’)` statement).

Durable execution makes it trivial or unnecessary to implement distributed systems patterns like event-driven architecture, task queues, [sagas](https://microservices.io/patterns/data/saga.html), [circuit breakers](https://microservices.io/patterns/reliability/circuit-breaker.html), and [transactional outboxes](https://microservices.io/patterns/data/transactional-outbox.html). It’s programming on a higher level of abstraction, where you don’t have to be concerned about transient failures like server crashes or network issues. It opens up new possibilities like:

- Storing state in local variables instead of a database, because local variables are automatically stored for us 
- Writing code that sleeps for a month, because we don’t need to be concerned about the process that started the sleep still being there next month, or resources being tied up for the duration
- Functions that can run forever, and that we can interact with (send commands to or query data from)

Some examples of durable execution systems are Azure Durable Functions, Amazon SWF, Uber Cadence, Infinitic, and [Temporal](https://temporal.io/) (where I work). At the risk of being less than perfectly objective, I think Temporal is the best of these options 😊.

# Durable JavaScript

Now that we’ve gone over consistency in distributed systems and what durable execution is, let’s look at a practical example. I built this food delivery app to show what durable code looks like and what problems it solves:

[temporal.menu](https://temporal.menu/)

![Durable Delivery app menu](//images.ctfassets.net/0uuz8ydxyd9p/23viK26Hvfx8jYCam3kC9r/36321dc6b375fe829a8c3e701b85bb9f/menu.jpg)

*Don’t blame me for the logo—that’s just what Stable Diffusion gives you when you ask it for a durable delivery app logo. 🤷‍♂️😄*

The app has four main pieces of functionality:

- Create an order and charge the customer
- Get order status
- Mark an order picked up
- Mark an order delivered

![The order process, showing both the menu and driver sites](//images.ctfassets.net/0uuz8ydxyd9p/5t9ArgfJP8K0UGFpOAzidi/5b37dc9c647370714bd5b53b692615d0/delivery-demo.gif)

When we order an item from the menu, it appears in the delivery driver site ([drive.temporal.menu](https://drive.temporal.menu)), and the driver can mark the order as picked up, and then as delivered.

All of this functionality can be implemented in a single function of durable JavaScript or TypeScript. We’ll be using the latter—I recommend TypeScript and our library is named the TypeScript SDK, but it’s published to npm as JavaScript and can be used in any Node.js project.

## Create an order

Let’s take a look at the code for this app. We’ll see a few API routes but mostly go over each piece of the single durable function named `order`. If you’d like to run the app or view the code on your machine, this will download and set up the project:

```sh
npx @temporalio/create@latest --sample food-delivery
```

When the user clicks the order button, the React frontend calls the `createOrder` mutation defined by the tRPC backend. The `createOrder` API route handler creates the order by starting a durable `order` function. Durable functions—called *Workflows*—are started using a Client instance from `@temporalio/client`, which has been added to the tRPC context under `ctx.temporal`. The route handler receives a validated `input` (an object with a `productId` number and `orderId` string) and it calls `ctx.temporal.workflow.start` to start an `order` Workflow, providing `input.productId` as an argument:

[apps/menu/pages/api/[trpc].ts](https://github.com/temporalio/samples-typescript/blob/main/food-delivery/apps/menu/pages/api/%5Btrpc%5D.ts)

```ts
import { initTRPC } from '@trpc/server'
import { z } from 'zod'
import { taskQueue } from 'common'
import { Context } from 'common/trpc-context'
import { order } from 'workflows'

const t = initTRPC.context<Context>().create()

export const appRouter = t.router({
  createOrder: t.procedure
    .input(z.object({ productId: z.number(), orderId: z.string() }))
    .mutation(async ({ input, ctx }) => {
      await ctx.temporal.workflow.start(order, {
        workflowId: input.orderId,
        args: [input.productId],
        taskQueue,
      })

      return 'Order received and persisted!'
    }),
```

The `order` function starts out validating the input, setting up the initial state, and charging the customer:

[packages/workflows/order.ts](https://github.com/temporalio/samples-typescript/blob/main/food-delivery/packages/workflows/order.ts)

```ts
type OrderState = 'Charging card' | 'Paid' | 'Picked up' | 'Delivered' | 'Refunding'

export async function order(productId: number): Promise<void> {
  const product = getProductById(productId)
  if (!product) {
    throw ApplicationFailure.create({ message: `Product ${productId} not found` })
  }

  let state: OrderState = 'Charging card'
  let deliveredAt: Date

  try {
    await chargeCustomer(product)
  } catch (err) {
    const message = `Failed to charge customer for ${product.name}. Error: ${errorMessage(err)}`
    await sendPushNotification(message)
    throw ApplicationFailure.create({ message })
  }

  state = 'Paid'
```

Any functions that might fail are automatically retried. In this case, `chargeCustomer` and `sendPushNotification` both talk to services that might be down at the moment or might return transient error messages like “Temporarily unavailable.” Temporal will automatically retry running these functions (by default indefinitely with exponential backoff, but that’s configurable). The functions can also throw non-retryable errors like “Card declined,” in which case they won’t be retried. Instead, the error will be thrown out of `chargeCustomer(product)` and caught by the catch block; the customer receives a notification that their payment method failed, and we throw an `ApplicationFailure` to fail the `order` Workflow.
## Get order status

The next bit of code requires some background: Normal functions can’t run for a long time, because they’ll take up resources while they’re waiting for things to happen, and at some point they’ll die when we deploy new code and the old containers get shut down. Durable functions can run for an arbitrary length of time for two reasons: 

- They don’t take up resources when they’re waiting on something.
- It doesn’t matter if the process running them gets shut down, because execution will seamlessly be continued by another process. 

So although some durable functions run for a short period of time—like a successful money transfer function—some run longer—like our order function, which ends when the order is delivered, and a customer function that lasts for the lifetime of the customer.

It’s useful to be able to interact with long-running functions, so Temporal provides what we call *Signals* for sending data into the function and *Queries* for getting data out of the function. The driver site shows the status of each order by sending Queries to the order functions through this API route:

[apps/menu/pages/api/[trpc].ts](https://github.com/temporalio/samples-typescript/blob/cb617abb3e0f58a6911c66615f9c2c665e0307b0/food-delivery/apps/menu/pages/api/%5Btrpc%5D.ts#L23-L25)

```ts
  getOrderStatus: t.procedure
    .input(z.string())
    .query(({ input: orderId, ctx }) => ctx.temporal.workflow.getHandle(orderId).query(getStatusQuery)),
```

It gets a handle to the specific instance of the order function (called a *Workflow Execution*), sends the `getStatusQuery`, and returns the result. The `getStatusQuery` is defined in the order file and handled in the order function:

[packages/workflows/order.ts](https://github.com/temporalio/samples-typescript/blob/cb617abb3e0f58a6911c66615f9c2c665e0307b0/food-delivery/packages/workflows/order.ts#L55-L57)

```ts
import { defineQuery, setHandler } from '@temporalio/workflow'

export const getStatusQuery = defineQuery<OrderStatus>('getStatus')

export async function order(productId: number): Promise<void> {
  let state: OrderState = 'Charging card'
  let deliveredAt: Date

  // …

  setHandler(getStatusQuery, () => {
    return { state, deliveredAt, productId }
  })
```

When the order function receives the `getStatusQuery`, the function passed to `setHandler` is called, which returns the values of local variables. After the call to `chargeCustomer` succeeds, the state is changed to `’Paid’`, and the driver site, which has been polling `getStatusQuery`, gets the updated state. It displays the “Pick up” button. 

## Picking up an order

When the driver taps the button to mark the order as picked up, the site sends a `pickUp` mutation to the API server, which sends a `pickedUpSignal` to the order function:

[apps/driver/pages/api/[trpc].ts](https://github.com/temporalio/samples-typescript/blob/main/food-delivery/apps/driver/pages/api/%5Btrpc%5D.ts)

```ts
  pickUp: t.procedure
    .input(z.string())
    .mutation(async ({ input: orderId, ctx }) => 
      ctx.temporal.workflow.getHandle(orderId).signal(pickedUpSignal)
    ),
```

The order function handles the Signal by updating the state:

[packages/workflows/order.ts](https://github.com/temporalio/samples-typescript/blob/cb617abb3e0f58a6911c66615f9c2c665e0307b0/food-delivery/packages/workflows/order.ts#L42-L46)

```ts
export const pickedUpSignal = defineSignal('pickedUp')

export async function order(productId: number): Promise<void> {
  // …

  setHandler(pickedUpSignal, () => {
    if (state === 'Paid') {
      state = 'Picked up'
    }
  })
``` 

Meanwhile, further down in the function, after the customer was charged, the function has been waiting for the pickup to happen: 

[packages/workflows/order.ts](https://github.com/temporalio/samples-typescript/blob/cb617abb3e0f58a6911c66615f9c2c665e0307b0/food-delivery/packages/workflows/order.ts#L70)

```ts
import { condition } from '@temporalio/workflow'

export async function order(productId: number): Promise<void> {
  // …

  try {
    await chargeCustomer(product)
  } catch (err) {
    // …
  }

  state = 'Paid'

  const notPickedUpInTime = !(await condition(() => state === 'Picked up', '1 min'))
  if (notPickedUpInTime) {
    state = 'Refunding'
    await refundAndNotify(
      product,
      '⚠️ No drivers were available to pick up your order. Your payment has been refunded.'
    )
    throw ApplicationFailure.create({ message: 'Not picked up in time' })
  }
```

`await condition(() => state === 'Picked up', '1 min')` waits for up to 1 minute for the state to change to `Picked up`. If a minute goes by without it changing, it returns false, and we refund the customer. (Either we have very high standards for the speed of our chefs and delivery drivers, or we want the users of a demo app to be able to see all the failure modes 😄.)

## Delivery

Similarly, there’s a `deliveredSignal` sent by the “Deliver” button, and if the driver doesn’t complete delivery within a minute of pickup, the customer is refunded.

[packages/workflows/order.ts](https://github.com/temporalio/samples-typescript/blob/cb617abb3e0f58a6911c66615f9c2c665e0307b0/food-delivery/packages/workflows/order.ts#L82-L89)

```ts
export const deliveredSignal = defineSignal('delivered')

export async function order(productId: number): Promise<void> {
  setHandler(deliveredSignal, () => {
    if (state === 'Picked up') {
      state = 'Delivered'
      deliveredAt = new Date()
    }
  })

  // …

  await sendPushNotification('🚗 Order picked up')

  const notDeliveredInTime = !(await condition(() => state === 'Delivered', '1 min'))
  if (notDeliveredInTime) {
    state = 'Refunding'
    await refundAndNotify(product, '⚠️ Your driver was unable to deliver your order. Your payment has been refunded.')
    throw ApplicationFailure.create({ message: 'Not delivered in time' })
  }

  await sendPushNotification('✅ Order delivered!')
```

If delivery was successful, the function waits for a minute for the customer to eat their meal and asks them to rate their experience.

```ts
  await sleep('1 min') // this could also be hours or even months

  await sendPushNotification(`✍️ Rate your meal. How was the ${product.name.toLowerCase()}?`)
}
```

After the final push notification, the order function’s execution ends, and the Workflow Execution completes successfully. Even though the function has completed, we can still send Queries, since Temporal has the final state of the function saved. And we can test that by refreshing the page a minute after an order has been delivered: the `getStatusQuery` still works and “Delivered” is shown as the status:

![Poke order with Status: Delivered](//images.ctfassets.net/0uuz8ydxyd9p/2IAEpuDtPpp8NNCjeswM2h/b783df7d5c1554a50aab7a4b427b89f3/delivered.png)

# Summary

We’ve seen how a multi-step order flow can be implemented with a single durable function. The function is guaranteed to complete in the presence of failures, including:

- Temporary issues with the network, data stores, or downstream services
- The process running the function failing
- The underlying Temporal services or database going down

This addressed a number of distributed systems concerns for us, and meant that: 

- We could use local variables instead of saving state to a database.
- We didn’t need to set timers in a database for application logic like canceling an order that takes too long or for the built-in functionality of retrying and timing out transient functions like `chargeCustomer`.
- We didn’t need to set up a job queue that workers polled, either for progressing to the next step or picking up unfinished tasks that were dropped by failed processes.

In the next post, we’ll look at more of the delivery app’s code and learn how Temporal is able to provide us with durable execution. To get notified when it comes out, you can follow us on [Twitter](https://twitter.com/temporalio) or [LinkedIn](https://www.linkedin.com/company/temporal-technologies/posts/).

If you have any questions, I would be happy to help! Temporal’s mission is helping developers, and I also personally find joy in it 🤗. I’m [@lorendsr](https://twitter.com/lorendsr) on Twitter, I answer (and upvote 😄) any StackOverflow questions tagged with [`temporal-typescript`](https://stackoverflow.com/questions/ask?tags=temporal-typescript), and am @Loren on the [community Slack](https://t.mp/slack) 💃.

# Learn more

To learn more, I recommend these resources:

- Video: [Intro to Temporal and using the TypeScript SDK](https://youtu.be/6lSuDRRFgyY)
- Some [common use cases](https://temporal.io/use-cases)
- TypeScript SDK docs: [t.mp/ts](https://t.mp/ts)
- TypeScript API reference: [t.mp/ts-api](https://t.mp/ts-api)
- [TypeScript tutorials](https://learn.temporal.io/tutorials/typescript/)

More blog posts about our TypeScript SDK:

- [Using Temporal as a Node.js Task Queue](https://temporal.io/blog/using-temporal-as-a-node-task-queue)
- [Caching API Requests with Long-Lived Workflows](https://temporal.io/blog/caching-api-requests-with-long-lived-workflows)
- [Express middleware that creates a REST API for your Workflows](https://temporal.io/blog/temporal-rest)
- [1.0.0 release of the TS SDK](https://temporal.io/blog/typescript-1-0-0)
- [How we use V8 isolates to enforce Workflow determinism](https://temporal.io/blog/intro-to-isolated-vm)

*💬 Discuss on [Hacker News](https://news.ycombinator.com/item?id=34462105#34463897), [Reddit](https://www.reddit.com/r/node/comments/10hagy8/building_reliable_distributed_systems_in_nodejs/), [Twitter](https://twitter.com/lorendsr/status/1616544308886118401), or [LinkedIn](https://www.linkedin.com/posts/temporal-technologies_building-reliable-distributed-systems-in-activity-7022335275880120320-BtAg).*

*Thanks to Jessica West, Brian Hogan, Amelia Mango, and Jim Walker for reading drafts of this post.*


Building Reliable Distributed Systems in Node.js

Developer Relations Engineer

Loren Sands-Ramshaw

Loren

menu-social

*J. H. Saltzer, D. P. Reed, and D. D. Clark. 1984.* [*End-to-end arguments in system design*](https://doi.org/10.1145/357401.357402)*. ACM Transactions on Computer Systems 2, 4 (Nov. 1984), 277–288.*

**Key Words** Function, Completeness, Correctness, Application Layer, Platform Layer, Failure, Failure Detection, Failure Mitigation.

In their 1984 paper End-to-End Arguments in System Design, Saltzer, Reed, and Clark present a design principle that helps guide placement of functions among the modules of a distributed system. In his paper, the term *functions* refers to *functionality*, not a particular function definition in a programming language. Similarly, the term *modules* refers to *layers*, not a particular organizational construct in a programming language.

Saltzer, Reed, and Clark assume a layered architectural style. The basic idea of a layered architecture is simple: components are arranged in a layered fashion where components at layer Lₙ can make a downcall to components at layer Lₘ (n < m), generally expecting a response. Exceptionally, components at layer Lₘ can make an upcall to components at layer Lₙ, generally via a previously registered callback.

For this blog post, we limit our discussion to two layers, we will refer to the top layer as the application layer and the lower layer as the platform layer. 

![Application Layer vs Platform Layer](//images.ctfassets.net/0uuz8ydxyd9p/5QtDbuv9rf3ix7K5MKqoIj/c1d40297db9288e711b912b4055e91d0/Application_vs_Platform.png)

## The End-to-End Argument

The End-to-End Argument states that some functions may “completely and correctly be implemented only” on an application level, implementing said functions completely and correctly on a platform level is not possible. This impossibility is rooted in the fact that the application layer has total information, the platform layer may only have partial information － informally, the platform layer lacks context.

However, the End-to-End Argument does not preclude to provide a partial, incomplete implementation of a function or to duplicate a function on a platform level, not for completeness and correctness but strictly as an optimization.

In addition, the paper stresses that the End-to-End Argument is a guideline that helps in application and platform design analysis; however, identifying the endpoints to which the argument should be applied requires subtlety of analysis of application requirements.

## Example

The significance of the End-to-End Argument is most apparent when reasoning about layers and failures: Is a layer able to detect a failure? If a layer is able to detect a failure, what should that layer do? Should the layer mitigate the failure? Should the layer present the failure to the next higher layer?

### Reliable File Transfer

The paper discusses several examples, however this blog posts limits itself to discussing one example: **Reliable File Transfer**.

The object is to move a file from computer A’s storage to computer B’s storage without damage. A popular implementation to transfer a file is to transfer the file in chunks:

- On the sender side, the application layer splits the data into chunks before handing each chunk downwards to the platform layer for transfer.

- On the receiver side, the platform layer receives a chunk before handing the chunk upwards to the application layer for assembly.

![Reliable File Transfer](//images.ctfassets.net/0uuz8ydxyd9p/3iNBZy1q2kWDBLTm827IAb/3b49ea6cca2b464ba3f92ca4227e9e98/Reliable_File_Transfer.png)

So now the question arises, can you implement file transfer completely and correctly by limiting failure detection and failure mitigation to the platform layer or do you need failure detection and failure mitigation (also) on the application layer?

#### Failure Detection and Mitigation

While the platform layer may indeed detect transmission failures of a chunks via checksums on chunks and mitigate failures via retransmissions of chunks, only the application layer may detect assembly failures on files via checksums on files and mitigate failures via retransmission of files.

#### Failure Presentation

While the platform layer may indeed try to mitigate transmission failures via retransmissions, eventually, in order to avoid an infinite loop, the platform level has to present repeated transmission failures to the application level.

In summary, although the platform layer implements partial failure detection and mitigation, ultimately only the application layer is able to implement total failure detection and mitigation － only the application layer may determine if a file transfer was a success, was a failure, and how to handle that failure.

## Conclusion

The End-to-End Argument states that some functions may "completely and correctly be implemented only" on an application level, even though the End-to-End Argument does not preclude partially implementing functions on a platform level as an optimization.

For example, failure detection and mitigation of a file transfer can (and should) happen on an application level and a platform level but only the application layer can ensure completeness and correctness of the transfer.

### Types of Optimization

- **Performance**. If the application layer detects a failure in the transmission of the file, the application layer may mitigate that failure by retransmitting the file. However, if the platform layer detects a failure in the transmission of a chunk, the platform layer may mitigate that failure by retransmitting only the chunk. We may be able to avoid retransmitting the file if retransmission of the chunk is successful.
- **Maturity**. Even though some functions may completely and correctly be implemented only on the application layer, duplicating functionality on the platform layer may aid correctness; some functions are complex and therefore error prone, encapsulating these functions in the platform layer enables us to take advantage of their maturity and “fill in the gap” of these functions in the application layer

Paper Summary, End-to-End Arguments in System Design

Failure, Failure Detection, Failure Mitigation, Failure Tolerance, Failure Mitigation

Paper Summary: End-to-End Arguments in System Design

Principal Engineer

Dominik Tornow

dominik-tornow

Imagine, two bleary-eyed college students scrambling late into the night to finish their last Computer Science project for the semester. The application they are writing takes a large problem and breaks it down into individual sub-problems that can be solved more easily. Unfortunately, there are too many subproblems for a single machine to handle, so the students realize they need to throw more machines into the mix.

Having quickly achieved consensus on the distributed algorithm, they get to work. All they have to do is implement their code and then deploy it on a set of machines. They figure they will be done within a couple of hours. Easy, right?

![temporal-a-students-dream-1](//images.ctfassets.net/0uuz8ydxyd9p/1l3Wo9ZnJgcns3YoSdJilP/4803982db40ac342aa1c51381a2e1f15/temporal-a-students-dream-1.png)

As they start coding, it quickly becomes clear that they have vastly underestimated the requirements. The algorithm works great on a laptop, but when it comes to executing it on a cluster of machines, they start asking themselves the following questions:

1. Which machine is responsible for coordinating (sending/receiving of sub-problems/results) with the other machines?
2. How do the other machines “know” who the coordinator is?
3. What protocol will be used so that the coordinator and workers are able to talk with each other? Do they need to handcraft a custom one?
4. What if the coordinator reboots or fails? Do they have to start solving the entire problem from the beginning again? Who takes over the coordinator role?
5. What if one of the “worker” machines recycles? Who tells the coordinator that it is not getting an answer back and that it needs to re-issue the subproblem?
6. What if work starts to pile up? How can we increase overall throughput by adding more worker machines in a balanced manner?
7. How does one make sure that a worker machine does not get assigned too many items?

![temporal-a-students-dream-2](//images.ctfassets.net/0uuz8ydxyd9p/1KW6yOUFL2G3oVnRZueuID/0316b9fede7992201c430d565a6a35d6/temporal-a-students-dream-2.png)

These questions touch upon a number of key Distributed Systems topics. But this was before cloud computing was the ubiquitous behemoth it is today. For two exhausted college students who were itching to call it quits on the semester, having to think through these problems at the 11th-hour was the absolute last thing they wanted to do.

Needless to say, in desperation, they took a number of shortcuts. They were able to cobble together a flimsy solution that yielded an answer; However, it would have fallen completely flat on its face at even the tiniest of network blips.

At the end of the day, they spent 95%+ of the time focusing on the infrastructure running the algorithm as opposed to the algorithm itself. As they dragged themselves back from that final class, one of them made an offhand remark that it could be an interesting future project to potentially “solve this the right way.”

![temporal-a-students-dream-3](//images.ctfassets.net/0uuz8ydxyd9p/4DeSveBNGqDpmNy8g6X8Nt/3ed59c550504ae91bc7332b578fd3d4f/temporal-a-students-dream-3.png)

If you haven't already figured it out by now, one of those college students was me. And after three months at Temporal, it has now just occurred to me: I am working on the very platform that my naïve college-aged self would have happily traded a week’s worth of cafeteria credits for. It is a platform that would have enabled us to actually complete the project within our hyper-aggressive initial estimate of a “couple of hours.” A Temporal cluster would have literally taken care of all of the questions we had to deal with above.

![temporal-a-students-dream-4](//images.ctfassets.net/0uuz8ydxyd9p/7eBCxvcXkZx8rHOCFn39is/d1aa088f3338c366a9d4155f6fbfc0af/temporal-a-students-dream-4.png)

It’s been over a decade since I’ve stepped back into a Computer Science class, but from a distance, I’ve seen curriculums evolve to keep up with the pace of technology. When I was graduating, they had just started to introduce map-reduce as a concept in our Operating Systems course. Now schools are offering classes on Bitcoin, Cloud Computing, No SQL databases, VR development and so on.

I truly believe that the concepts behind Temporal deserve at least a lecture or two in any standard undergraduate Distributed Systems course. Given how powerful Temporal is, I predict this will be the case in the future.

shubham-dhage-8ZGZlksF8mo-unsplash

Imagine, two bleary-eyed college students scrambling late into the night to finish their last Computer Science project for the semester. 

Building Reliable Distributed Systems in Node.js

Paper Summary: End-to-End Arguments in System Design

Temporal - a students dream