The structural decisions that decide what your product can do next, explained for the person planning around them.
Architecture decisions are the ones that are expensive to reverse, which makes them roadmap decisions as much as engineering ones. This list gives a product or delivery lead enough grounding to take part in them, covering architecture characteristics and the tradeoffs between them, the data layer, API design, and the reliability and security concerns that arrive with scale. It closes with the organisational point, which is that a system tends to take the shape of the teams that built it.
Richards and Ford set out the architecture styles alongside the characteristics they trade off, and argue that everything here is a tradeoff rather than a best practice. Architecture decision records alone are worth adopting from this book.
Kleppmann on replication, partitioning, transactions and consistency, which is the material behind most of the estimates you are given for anything touching scale. The chapter summaries carry the argument when the full detail is more than you need.
Lauret on designing an interface around the people consuming it rather than around the database sitting behind it. Directly relevant when the API is the product and developer experience is the user experience.
Reis and Housley on ingestion, storage, transformation and serving, and the early choices that decide what analytics you can offer later. Read it before agreeing an event schema you will live with for several years.
Service level objectives and error budgets turn reliability into a number you can plan against instead of a recurring argument. That makes this the most useful book here for a roadmap conversation about non functional work.
Shostack's four question framework and STRIDE put security into the design stage rather than into a late review. Worth the time if your architecture handles payments, personal data or anything a regulator takes an interest in.
Conway's law says the system will mirror the communication structure that produced it, which makes the org chart an architecture decision. Skelton and Pais give you four team types and a way to use that effect on purpose.