EP56: System Design Blueprint: The Ultimate Guide

This week’s system design refresher:

• API Architecture Styles

• System Design Blueprint: The Ultimate Guide

• What companies think A.I. looks like

• Amazon's innovative build system

• McDonald’s event-driven architecture

• Job openings

---

How many API architecture styles do you know?

Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles:

• SOAP:
  Mature, comprehensive, XML-based
  Best for enterprise applications

• RESTful:
  Popular, easy-to-implement, HTTP methods
  Ideal for web services

• GraphQL:
  Query language, request specific data
  Reduces network overhead, faster responses

• gRPC:
  Modern, high-performance, Protocol Buffers
  Suitable for microservices architectures

• WebSocket:
  Real-time, bidirectional, persistent connections
  Perfect for low-latency data exchange

• Webhook:
  Event-driven, HTTP callbacks, asynchronous
  Notifies systems when events occur

Over to you: Are there any other famous styles we missed?

---

System Design Blueprint: The Ultimate Guide

We've created a template to tackle various system design problems in interviews.

Thanks, Love Sharma, for putting it together.

Hope this checklist is useful to guide your discussions during the interview process.

This briefly touches on the following discussion points:

• Load Balancing

• API Gateway

• Communication Protocols

• Content Delivery Network (CDN)

• Database

• Cache

• Message Queue

• Unique ID Generation

• Scalability

• Availability

• Performance

• Security

• Fault Tolerance and Resilience

• And more

---

What companies think A.I. looks like

True or false? And what is missing?

Image credit: Andy Scherpenberg

---

Discover Amazon's innovative build system - Brazil.

Amazon's ownership model requires each team to manage its own repositories, which allows for more rapid innovation. Amazon has created a unique build system, known as Brazil, to enhance productivity and empower Amazon’s micro-repo driven collaboration. This system is certainly worth examining!

With Brazil, developers can focus on developing the code and creating a simple-to-understand build configuration file. The build system will then process the output artifact repeatedly and consistently. The build config minimizes the build requirement, including language, versioning, dependencies, major versions, and lastly, how to resolve version conflicts.

For local builds, the Brazil build tool interprets the build configuration as a Directed Acyclic Graph (DAG), retrieves packages from the myservice’s private space (VersionSet) called myservice-cpp-version-set, generates the language-specific build configuration, and employs the specific build tool to produce the output artifact.

A version set is a collection of package versions that offers a private space for the package and its dependencies. When a new package dependency is introduced, it must also be merged into this private space. There is a default version set called "live," which serves as a public space where anyone can publish any version.

Remotely, the package builder service provides an intuitive experience by selecting a version set and building targets. This service supports Amazon Linux on x86, x64, and ARM. Builds can be initiated manually or automatically upon a new commit to the master branch. The package builder guarantees build consistency and reproducibility, with each build process being snapshotted and the output artifact versioned.

Over to you - which type of build system did you use?

---

McDonald’s event-driven architecture

Think you know everything about McDonald's? What about its event-driven architecture?

McDonald's standardizes events using the following components:

• An event registry to define a standardized schema.

• Custom software development kits (SDKs) to process events and handle errors.

• An event gateway that performs identity authentication and authorization.

• Utilities and tools to fix events, keep the cluster healthy, and perform administrative tasks.

To scale event processing, McDonald uses a regional architecture that provides global availability based on AWS. Within a region, producers shard events by domains, and each domain is processed by an MSK cluster. The cluster auto-scales based on MSK metrics (e.g., CPU usage), and the auto-scale workflow is based on step-functions and re-assignment tasks.

Reference: Behind the scenes: McDonald’s event-driven architecture

---

Join the ByteByteGo Talent Collective

If you’re looking for a new gig, join the collective for customized job offerings from selected companies. Public or anonymous options are available. Leave anytime.

If you’re hiring, join the ByteByteGo Talent Collective to start getting bi-monthly drops of world-class hand-curated engineers who are open to new opportunities.

Featured job openings

X1 Card: Engineering Leader - Card Platform (United States, remote)

X1 Card: Software Engineer, Back End, All Levels (United States, remote)

(catch) Health: Senior Frontend Engineer, React + Typescript (United States, remote)