Serverless Handbook

Student Login

Robust backend design

Imagine you're a Roman general leading a vast and powerful army. You're about to attack a city.

But you can't do it alone.

Your buddy with another vast and powerful army hides behind a hill on the other side. You need their help to win.

Attack together and win. Attack alone and die.

How do you ensure a joint attack?

Two generals problem
Two generals problem

Smoke signals would reveal your plan to the city. It's too far to shout and phones are 2000 years in the future.

A messenger is your best bet. Run to the other army, deliver the message, come back with confirmation.

Unless they're caught. 🤔

The messenger could fail to deliver your message. Or get caught on their way back. You'll never know.

Send more messengers until one makes it back? How does your friend know that any messenger made it back? Nobody wants to attack alone.

This puzzle is known as the Two Generals' Problem. There is no solution.

No algorithm guarantees 100% certainty over a lossy medium. Best you can do is "Pretty sure."

And that's why distributed systems are hard.

You cannot have 100% reliability. As soon as servers talk to each other, you're doomed to probabilities.

Serverless systems are always distributed. 😅

Build a robust backend

A robust backend keeps working in the face of failure.

As we mentioned in the Architecture Principles chapter, your backend follows 3 principles:

  1. Everything can and will fail
  2. Your system should keep working
  3. Failures should be easy to fix

You get there with a combination of error recovery, error isolation, and knowing when your system needs help.

The strategies mentioned in Architecture Principles were:

  • isolate errors
  • retry until success
  • make operations replayable
  • be debuggable
  • remove bad requests
  • alert the engineer when something's wrong
  • control your flow

This chapter talks about how.

Isolate errors

In March 2017, Amazon S3 went down and took with it half the internet. Root cause was a typo.

AWS Engineers were testing what happens when a few servers go offline. A typo took out too many and the rest got overwhelmed. They started failing one by one.

Soon the whole system was down.

And because AWS relies on S3 to store files ... much of AWS went down. And because half the internet runs on AWS ... it went down.

AWS couldn't even update their status dashboard because error icons live on S3.

To isolate errors you have to reduce inter-dependency. Always think: "What can I do to make moving pieces less dependent on each other?"

In your car, the brakes keep working even if your brake lights go out. The systems work together, but independently.

Inter-dependency can be subtle and hard to spot. The specifics are different each time.

Here are 3 rules:

  1. Give each operation a single responsibility
  2. Do the whole operation in one atomic go
  3. Avoid coupling

Serverless functions are optimized for this approach by default. They encourage you to keep code light and isolated 🤘

Hello! 👋

Are you a frontend engineer diving into backend? Do you have just that one bit of code that can't run in the browser? Something that deals with secrets and APIs?

That's what cloud functions are for my friend. You take a JavaScript function, run it on serverless, get a URL, and voila.

But that's easy mode. Any tutorial can teach you that.

What happens when you wanna build a real backend? When you want to understand what's going on? Have opinions on REST vs GraphQL, NoSQL vs. SQL, databases, queues, talk about performance, cost, data processing, deployment strategies, developer experience?


Unlock your free chapter!

Access to this chapter immediately, extra free chapter and Serverless crash course in your email ✌️

I like privacy too. No spam, no selling your data.

buy now amazon

Dive into modern backend. Understand any backend

Serverless Handbook shows you how with 360 pages for people like you getting into backend programming.

With digital + paperback content Serverless Handbook has been more than 1 year in development. Lessons learned from 14 years of building production grade websites and webapps.

With Serverless Handbook, Swiz teaches the truths of distributed systems – things will fail – but he also gives you insight on how to architect projects using reliability and resilience perspectives so you can monitor and recover.

~ Thai Wood, author of Resilience Roundup

If you want to understand backends, grok serverless, or just get a feel for modern backend development, this is the book for you.

Serverless Handbook full of color illustrations, code you can try, and insights you can learn. But it's not a cookbook and it's not a tutorial.

Serverless Handbook on your bookshelf
Serverless Handbook on your bookshelf

Yes, there's a couple tutorials to get you started, to show you how it fits together, but the focus is on high-level concepts.

Ideas, tactics, and mindsets that you need. Because every project is different.

The Serverless Handbook takes you from your very first cloud function to modern backend mastery. In the words of an early reader:

Serverless Handbook taught me high-leveled topics. I don't like recipe courses and these chapters helped me to feel like I'm not a total noob anymore.

The hand-drawn diagrams and high-leveled descriptions gave me the feeling that I don't have any critical "knowledge gaps" anymore.

~ Marek C, engineer

If you can JavaScript, you can backend.

Plus it looks great on your bookshelf 😉

buy now amazon


Lambdas, queues, etc
Where to store data
Created bySwizecwith ❤️