Platform layer

As explained in Think Distributed Systems

The platform layer is the architectural layer providing the infrastructure and runtime environment for applications.

The platform layer is the lower-level environment that supports an application layer. Its identity is contextual: an operating system treats hardware as its platform, while a database management system treats the operating system and hardware as its platform. section 3.3.3

A layered system arranges components vertically. Higher layers usually make downcalls to lower layers and expect responses; lower layers may make upcalls through registered callbacks. Systems may also distinguish application, platform, and infrastructure layers. section 3.3.3

One component, different layer

For a database management system, the database is the application layer, the operating system is the platform layer, and hardware is the infrastructure layer. For the operating system, however, the operating system becomes the application layer and hardware becomes the platform layer. section 3.3.3

Use the platform layer to assign responsibility for failures:

• Handle an unambiguous application-level failure at the application layer, such as compensating for completed e-commerce steps after an insufficient-funds error. section 3.3.6
• Mitigate transient platform failures with an immediate retry, intermittent failures with backoff and multiple retries, and permanent failures by suspending, repairing, and resuming. section 3.3.6
• Elevate an unsuccessful platform mitigation to the application, and escalate recovery failures that require human intervention to operators. section 3.3.6

Figure 3.9 Thinking in layers

Visualizes the downcall and upcall relationships that define the layered mental model. section 3.3.3

Figure 3.16 Outline of failure-handling strategy in an orchestration scenario

Maps failure classification to an escalating platform-level mitigation strategy. section 3.3.6

How Think Distributed Systems covers it

How deep it goes

Explains layered roles and specifies retry, backoff, repair, suspension, resumption, and escalation, but not implementation internals.

Examples

Uses operating systems, hardware, database management systems, insufficient-funds errors, retries, backoff, repair, and manual refunds.

What it assumes

Builds from layered architecture and introduces the application/platform distinction before applying it to failure handling.

What you can do after

Diagnose failures by layer and apply retries, backoff, repair, resumption, or escalation to the appropriate responsibility level.

How it connects

Connects layered architecture with application layers, infrastructure layers, failure classification, backward recovery, and the end-to-end argument.

liveBookmanning.com

Read Think Distributed Systems on liveBook Get the book at manning.com

Related concepts

• platform-level failureaddresses · A failure reported by the software or infrastructure platform when an operation cannot be connected or executed at that platform level.
• internal developer platformpart of · An internal developer platform is an organization-provided system of self-service interfaces, automation, abstractions, and reusable capabilities that supports software development and operation.

This explainer was generated by Manning's knowledge graph from the text of Think Distributed Systems. The section links point to the parts of the book it draws on.