Curated Tech Reading Map

Find your next tech book to read

Domain

Backend Development

A learning path to systematically build implementation skill and design principles for backend development — from API design and server-side architecture to authentication, async processing, distributed systems, and performance optimization.

The Terrain of This Field

The terrain of backend development can be read as a single continent you climb from the coastal lowlands to the inland highlands. The shoreline is the trailhead of "language and quality" — the foundation that lifts you from merely making code run toward code that is readable and easy to change.

At the mid-slopes the path forks into two ridges. One is the ridge of "communication and interfaces," rising from TCP/IP through web APIs and authentication. The other is the ridge of "design," from class-level design patterns up to system-wide dependency design (clean architecture). The two can be climbed independently, but they converge at the pass of frameworks.

Deeper inland rise the mountains of "scale, data, and stability" beyond a single server: the judgment of splitting a monolith into microservices, the patterns that implement it, designs that withstand failure, and the summit of data-intensive design. The key to surveying this field is that the scale of concerns connects continuously — from a single line of code to large-scale operations.

Follow the arrows to read in order / solid = required, dashed = recommended

Share this map

Difficulty

Beginner
Intermediate
Advanced

Dependencies

Prerequisite
Recommended
Related

Computing layout...

Books in this domain

Difficulty
Reading status
Tags

37 books

Dependencies

  1. 01Sukkiri Wakaru Java Nyumon (A Clear Introduction to Java)Clean CodeRecommended / From Java basics to code quality

    Reason: Once you can write basic Java syntax, the next step is to raise your sights from merely working code to code that is readable and easy to change. Clean Code provides principles for naming, function decomposition, and comments—building the sense of quality that is hard to acquire on your own.

  2. Reason: Once you can write clean functions and classes, it's time to learn design patterns—named solutions to recurring design problems—through Java code. This book lets you experience the 23 GoF patterns in Java implementations, building a vocabulary of reusable designs and the ability to compose relationships between classes with clear intent.

  3. Reason: With Java fundamentals in place, you move on to the Spring Framework, the de facto standard for server-side development in practice. Concepts like DI, AOP, and MVC assume a grasp of plain Java, so you layer the framework's abstractions onto your language understanding step by step.

  4. Reason: Once you can wield class-level patterns, you broaden your view to how dependencies and boundaries are designed across the whole system. Clean Architecture offers the Dependency Rule—pushing details outward and keeping business rules at the center.

  5. Reason: Once you understand how TCP/IP and HTTP work, the design decisions of REST APIs built on top of them make sense down to the 'why.' Web API: The Good Parts offers practical guidance on URIs, methods, and status codes grounded in HTTP semantics.

  6. Reason: After grasping how networks work, you descend to the OS layer that actually handles that communication. Linux system programming introduces the APIs—sockets, processes, file descriptors—on which servers run, bridging protocol and implementation.

  7. Reason: This is the stage where protocol understanding connects to building a server that actually runs. System programming in Go shows how to write network services in a language strong at concurrency, turning TCP/IP knowledge into working code.

  8. Reason: Knowing the OS-level mechanisms for processes, I/O, and memory lets you see what Spring abstracts away under the hood. This low-level understanding keeps the framework from being a black box and pays off when diagnosing performance issues and failures.

  9. Reason: Having once felt the effort of writing a server with raw system programming, you grasp viscerally what a framework like Spring takes off your hands. Low-level experience gives you perspective to weigh a framework's convenience against its constraints.

  10. 10Web API: The Good PartsThe Design of Web APIsRecommended / From REST basics to OpenAPI in practice

    Reason: Once you've grasped the basics of REST design, you advance to describing and sharing an API as a 'contract.' The Design of Web APIs presents a spec-driven design process with OpenAPI, giving you a repeatable way to build consistent APIs across a team.

  11. 11Web API: The Good PartsLearning GraphQLRelated / From REST design to GraphQL

    Reason: Understanding REST design throws GraphQL's ideas into relief as an answer to REST's constraints—over-fetching and round trips. Learning GraphQL teaches client-driven queries and a schema-driven type system, giving you criteria for choosing between the two.

  12. 12Web API: The Good PartsgRPC: Up and RunningRelated / From REST design to gRPC

    Reason: With text-based REST in hand, you broaden your view to gRPC as a high-efficiency option for service-to-service communication. gRPC: Up and Running teaches contract definition with Protocol Buffers and bidirectional streaming, presenting a practical answer for internal microservice communication.

  13. 13The Design of Web APIsLearning GraphQLRelated / From OpenAPI to GraphQL

    Reason: Having experienced design-driven REST described with OpenAPI, you compare GraphQL, which realizes the same 'schema-first' idea in a different shape. The shared emphasis on designing APIs around a typed schema—and the difference in query models—deepens your understanding.

  14. 14The Design of Web APIsgRPC: Up and RunningRelated / From OpenAPI to gRPC

    Reason: Comfortable with contract design via OpenAPI, you move to gRPC, which uses Protocol Buffers as a stricter, binary-efficient contract. Comparing the experience of generating types and stubs from a schema reveals the breadth of contract-driven development.

  15. 15Spring Tettei Nyumon (A Thorough Introduction to Spring)Clean ArchitectureRecommended / From framework practice to design principles

    Reason: Once you can build applications with Spring, you start to feel the limits of framework-driven design centered on the database or the framework. Clean Architecture provides the Dependency Rule that keeps business rules independent of the framework, letting you choose a structure resilient to change over the long term.

  16. 16Clean ArchitectureMonolith to MicroservicesRecommended / From design principles to deciding where to split services

    Reason: Once you can design boundaries inside a system, you face the next decision: whether to split those boundaries into separate processes—services. Monolith to Microservices, guided by the pragmatic 'monolith first' principle, systematizes the motivations, methods, and pitfalls of decomposition.

  17. 17Web API: The Good PartsOpenID Connect Nyumon (Introduction to OpenID Connect)Recommended / From API design to authorization implementation

    Reason: Once you can design an API, you need an authentication and authorization layer that controls who may call it and with what privileges. OpenID Connect standardizes identity verification on top of OAuth 2.0, providing the established way to build token-based access control into an API.

  18. 18Spring Tettei Nyumon (A Thorough Introduction to Spring)OpenID Connect Nyumon (Introduction to OpenID Connect)Related / From framework implementation to authentication implementation

    Reason: Once you can assemble an application's skeleton with Spring, you add the authentication and authorization that production demands. Understanding the OpenID Connect flow—authorization codes, tokens, ID tokens—makes Spring Security configuration click as 'configuration for a purpose.'

  19. Reason: Once you handle databases with Spring, the quality of the SQL and table design running behind the ORM starts to govern performance and maintainability. This book teaches the principles of relational design from a practitioner's angle, framed around the antipatterns people commonly fall into.

  20. Reason: Architecturally, the database sits on the outside as a 'detail,' but neglecting that detail—relational design—breaks down in practice. Learning the antipatterns sharpens your instincts for schema design, reconciling the ideal of abstraction with the reality of implementation.

  21. Reason: Once you can do basic system programming in Go, you dig deep into concurrency—Go's greatest strength. Concurrency in Go systematizes the design of coordinating 'by communicating rather than sharing memory' using goroutines and channels, teaching how to build safe concurrent programs.

  22. 22Concurrency in GoMicroservices PatternsRecommended / From single-node concurrency to messaging between services

    Reason: Having understood concurrency within a single process, you extend to a world where multiple processes—services—coordinate asynchronously. Microservices Patterns provides coordination patterns for distributed systems—messaging, sagas, event-driven design—extending the idea of concurrency across the network.

  23. 23Monolith to MicroservicesMicroservices PatternsRecommended / From deciding to split to the patterns that implement it

    Reason: Once you can decide whether to split a monolith, you stock up on the implementation patterns needed after the split. Microservices Patterns catalogs the established practices for service decomposition, data management, communication, and deployment, bridging from 'how to divide' to 'how to build.'

  24. 24Clean ArchitectureMicroservices PatternsRecommended / From design principles to distributed implementation

    Reason: Once you can design boundaries and dependencies within a single process, you scale those principles to distributed systems. Microservices Patterns gives you the vocabulary for designing inter-service communication, consistency, and failure handling while preserving each service's internal architecture.

  25. 25Microservices PatternsRelease It!, 2nd EditionRecommended / From distributed implementation to designing for stability

    Reason: Once you can implement distributed systems, designing 'how they behave when they break' becomes essential. Release It! provides stability patterns like circuit breakers and bulkheads, teaching you to design systems where failures don't cascade.

  26. 26Concurrency in GoRelease It!, 2nd EditionRelated / From concurrency to designing for failure

    Reason: Once you can write concurrent code, you face 'concurrency-born' failures—timeouts, retries, resource exhaustion. Release It! provides stability patterns that assume such failures, teaching designs that let concurrent code survive in production.

  27. Reason: Having understood the design of a single relational database, you broaden your view to the big picture of large-scale systems involving multiple data stores. Designing Data-Intensive Applications systematizes the fundamentals of data systems—replication, partitioning, consistency, faults—without being swayed by passing trends.

  28. 28Microservices PatternsDesigning Data-Intensive ApplicationsRecommended / From distributed patterns to the theory underneath

    Reason: Learning microservice implementation patterns, you inevitably hit the hard problem of keeping data consistent across services. Designing Data-Intensive Applications supplies the theory of distributed-data consistency, replication, and transactions, underpinning why those patterns work.

  29. Reason: Having grasped the theory of data systems, you flesh it out with a concrete example of how it's applied in a real service. 'The Technology Behind Dragon Quest X' concretely describes the operation, scaling, and incident response of a large-scale online game, giving abstract principles a tangible feel.

  30. Reason: After learning the design principles of robust systems through stability patterns, you learn from a case that practiced them in long-term operation. The continuous operation of a large-scale online game is a living lesson in how theoretical stability design is tested by real-world load and failures.

  31. 31Clean ArchitectureUnit Testing Principles, Practices, and PatternsRecommended / From architecture to test design

    Reason: Learning an architecture that controls the direction of dependencies makes you want testing principles that maximize the resulting testability. Unit Testing: Principles, Practices, and Patterns defines what a good test is, converting the loose coupling your architecture enables into testing value.

  32. Reason: Once you can write applications with Spring, you learn the principles for writing unit tests that guarantee their behavior correctly. Understanding not just the quantity of tests but their quality—what to verify and what to mock—lets you grow a test suite that is resilient to change and not brittle.

  33. 33Unit Testing Principles, Practices, and PatternsTesting Web APIsRecommended / From unit testing to an API testing strategy

    Reason: Having mastered unit testing principles, you broaden your view to a testing strategy for APIs that cross service boundaries. Testing Web APIs shows how to balance the upper layers of the test pyramid—integration, contract, end-to-end—securing the API reliability that unit tests alone can't protect.

  34. 34The Design of Web APIsTesting Web APIsRelated / From API design to contract testing

    Reason: Once you can design an API, you need a way to verify that the design keeps working as promised. Testing Web APIs introduces contract testing, letting you catch mismatches between provider and consumer in CI.

  35. 35Microservices PatternsTesting Web APIsRelated / From distributed implementation to contract testing

    Reason: Splitting into services creates the risk that integrations break whenever an inter-service interface changes. Testing Web APIs provides a contract-testing strategy including consumer-driven contracts (CDC), weaving a verification net that keeps independent deployment safe.

  36. 36Clean CodeWeb API: The Good PartsRelated / From code-quality awareness to API design

    Reason: A sense for good code carries over from the inside of functions and classes to the design of the APIs you expose. The Clean Code principles of naming, consistency, and predictability extend naturally to URIs and response design—the 'public names' of an API.

  37. Reason: Building on TCP/IP fundamentals, you systematically revisit the technologies that make the Web work—HTTP, URIs, HTML. This consolidates a shared vocabulary, explaining everything from protocols to architecture in one thread before moving on to REST design.

  38. 38Web o Sasaeru Gijutsu (The Technology That Supports the Web)Web API: The Good PartsRecommended / From web technology fundamentals to REST API design

    Reason: Once you have the Web's foundational technologies down, you move to the practice of designing 'good APIs' with them. Web API: The Good Parts offers established patterns for URI design, error representation, and versioning faithful to HTTP semantics, turning principles into design decisions.

  39. 39Web o Sasaeru Gijutsu (The Technology That Supports the Web)The Design of Web APIsRelated / From Web fundamentals to practical API design

    Reason: With the Web's foundations understood, you advance to viewing API creation as a systematic design process. The Design of Web APIs connects user-centered API design with description via OpenAPI, showing how to design APIs as a methodology rather than by improvisation.

  40. 40Building MicroservicesBuilding Applications with AI AgentsRelated / From microservices to multi-agent systems

    Reason: Learning to design 'autonomous parts that coordinate' with microservices, the idea carries over to multi-agent design that coordinates several AI agents. Practical AI Agent Development becomes an entry point for applying the sense of loose coupling, communication, and responsibility division cultivated in service decomposition to AI systems.

  41. 41Designing Data-Intensive ApplicationsBuilding Applications with AI AgentsRecommended / From distributed data systems to AI agent design

    Reason: Having grasped the theory of consistency, reliability, and scale in large-scale data systems, you see it as the foundation for putting AI agents into production. Practical AI Agent Development bridges the robustness principles learned in data-intensive systems to designing agent state management and tool integration.

  42. Reason: Once you grasp how LLMs process input and generate responses, plus the fundamentals of prompt design and context construction, you can see what abstractions a framework like LangChain takes off your hands. This book's insights on issues like Lost in the Middle and the volatility of conversation history give you criteria for designing context when building agents with LangChain.

  43. 43Context EngineeringTsukutte Manabu AI Agent (Learning AI Agents by Building One)Recommended / From LLM principles to building your own agent

    Reason: Understanding how to call LLM APIs and the basics of context design lets you keep sight of what's happening behind the reasoning loop and tool calls when building an agent from scratch in TypeScript. The context-engineering knowledge underpins the design decisions behind a self-built coding agent like Nano Code.

  44. Reason: Having gone through the basic design and implementation patterns of agents with LangChain, you start to see the design challenges of multi-agent systems that go beyond a single agent. Practical AI Agent Development builds up production-facing perspectives—orchestration, evaluation, monitoring, security—that framework learning alone doesn't cover.

  45. Reason: Having built a coding agent from scratch in TypeScript, you internalize the inner workings of the reasoning loop and tool integration. Practical AI Agent Development builds on that implementation sense, broadening the view from a single agent to multi-agent systems and production operation.

  46. Reason: Once you can use an AI coding agent like Claude Code effectively, you start wanting to build one yourself to see what's happening inside. Building AI Agents walks through implementing everything from LLM calls to tool execution and Git/GitHub integration, shifting your perspective from using such a tool to building one.

  47. Reason: Grasping the whole picture of ID management—from signup to logout to identity federation—in plain language lays the groundwork for the more specialized, detailed implementation covered by the OAuth 2.0 and OIDC protocol specs. Having organized the relationships among identity verification, authentication, and session management in Getting Started with Digital Identity makes it easier to place the authorization code flow and token validation covered in Introduction to OpenID Connect.

  48. 48The Design of Web APIsSecure APIsRecommended / From API design practice to implementing security

    Reason: Having grasped the practice of API design—contract-first with OpenAPI, pagination, versioning—you start to see the next challenge: how to build security into that design. Secure APIs builds up a shift-left perspective, addressing authentication/authorization vulnerabilities and API configuration risks starting from the design stage.

  49. Reason: After getting hands-on with setup, basic operation, and features like MCP servers and skills in 'Claude Code Practical Guide,' the next step is to rethink how you use those features at all. 'Practical Claude Code Introduction' doesn't repeat operational steps—it addresses the spec-driven development mindset that pulls you out of vibe coding, and the CLAUDE.md-based practice of building agreement with the agent.

  50. 50Jissen Claude Code Nyumon (A Practical Introduction to Claude Code)Tsukutte Manabu AI Agent (Learning AI Agents by Building One)Recommended / From the spec-driven development mindset to building your own agent

    Reason: Once you've reframed Claude Code as an 'agent that executes agreements' and internalized the spec-driven development pattern, you naturally want to see with your own hands what happens inside such an agent. Building AI Agents pushes you from being a user to a builder by having you implement the reasoning loop and tool calls in TypeScript yourself.

  51. 51Web o Sasaeru Gijutsu (The Technology That Supports the Web)Understanding Distributed Systems, 2nd EditionRecommended / From HTTP and REST basics to the whole of a distributed application

    Reason: The first part of Understanding Distributed Systems works through TCP, TLS and DNS and ends with a chapter that describes implementing a RESTful HTTP API; the later parts are about scaling a web application with such an API and keeping it running through failures. With HTTP methods, status codes and resource design already familiar, you can read the communication part as review and spend your time on coordination, scalability and resiliency.

  52. 52Understanding Distributed Systems, 2nd EditionDesigning Data-Intensive ApplicationsRecommended / From a broad map of distributed systems to data systems in depth

    Reason: The author of Understanding Distributed Systems says himself that the book favors breadth over depth and may not suit readers with years of experience. Replication, partitioning, transactions and consistency models each get a chapter or a section. Designing Data-Intensive Applications spends a whole book on those subjects, and is easier to enter once the first book has given you the vocabulary and a sense of where each piece sits.

  53. 53Understanding Distributed Systems, 2nd EditionMicroservices PatternsRelated / From an introduction to sagas and API gateways to the patterns in detail

    Reason: Understanding Distributed Systems introduces the outbox pattern and sagas in its chapter on asynchronous transactions, API gateways in its chapter on microservices, and asynchronous messaging in its chapter on messaging. Each is a short introduction. When the time comes to design with them, Microservices Patterns treats the same material as patterns, in detail.

  54. 54Understanding Distributed Systems, 2nd EditionRelease It!, 2nd EditionRecommended / From a survey of resiliency patterns to production failures and stability patterns

    Reason: The Resiliency part of Understanding Distributed Systems goes from common failure causes, redundancy and fault isolation to timeouts, retries, circuit breakers, load shedding and rate limiting. Release It! spends a whole book on stability patterns such as circuit breakers, bulkheads and timeouts, alongside case studies of production failures, so the patterns you met by name and purpose in the first book can be read again in the setting of real outages.

  55. 55Enterprise Integration PatternsMicroservices PatternsRecommended / From messaging patterns to communication between services

    Reason: Enterprise Integration Patterns organizes messaging channels, message construction, routing, transformation and endpoints with a vocabulary and a visual notation that do not depend on a product. Microservices Patterns takes up the problems that appear once a monolith is decomposed into services: interprocess communication between them, and transactions that span them, handled with sagas. With the messaging vocabulary of the first book in place, the second book's discussion of asynchronous communication can be followed from the ground up.

  56. 56Understanding Distributed Systems, 2nd EditionEnterprise Integration PatternsRelated / From one chapter on messaging to a catalog of messaging patterns

    Reason: Understanding Distributed Systems spends one chapter on messaging: the benefits and pitfalls of decoupling communication between services with asynchronous messaging channels. Enterprise Integration Patterns gives the whole book to messaging, dividing channels, routing, transformation, endpoints and system management into 65 patterns. It is where a reader whose interest starts in that chapter goes for the same subject in detail.

  57. Reason: The principles of test design carry over to the frontend. Building on the test pyramid, you cover the essentials of the UI with a few end-to-end tests and protect logic densely with unit tests—the criteria stay the same across layers.

  58. Reason: After comparing AI tools across the whole development process — code generation, review, test automation, documentation — and gaining criteria for 'which tool, when,' you naturally want to pick one and go deep hands-on. Claude Code Practical Guide builds up, from setup and conversational operation to extension via MCP servers and skills, focused on a single AI coding agent, turning the broad view of tool selection into concrete operational skill you can use in practice.

Explore next

Connected fields