What is *Designing Data-Intensive Applications* by Martin Kleppmann about?

*Designing Data-Intensive Applications* explores principles for building reliable, scalable, and maintainable data systems. It covers data models, storage engines, distributed systems challenges (replication, partitioning, consensus), and modern processing paradigms (batch and stream). The book emphasizes trade-offs over specific tools, offering a foundational guide for architects and engineers navigating complex data infrastructure.

Who should read *Designing Data-Intensive Applications*?

Software engineers, architects, and technical leaders working on data-heavy systems will benefit most. It’s ideal for those designing databases, distributed systems, or real-time processing pipelines. The book balances theory (e.g., CAP theorem) with practical insights, making it valuable for both learners and experienced practitioners.

Is *Designing Data-Intensive Applications* worth reading?

Yes—it’s widely regarded as a seminal resource for understanding data systems. Reviews praise its clarity, depth, and relevance to real-world challenges like scalability and fault tolerance. The book’s focus on enduring principles (vs. fleeting tools) ensures long-term value.

What data models are discussed in *Designing Data-Intensive Applications*?

Kleppmann compares **relational**, **document**, and **graph** models, highlighting their strengths: | **Model** | **Strengths** | |------------------|-----------------------------------------------| | Relational | Joins, schema enforcement | | Document | Schema flexibility, locality optimizations | | Graph | Complex relationships (e.g., social networks) | The analysis helps readers choose models based on use-case requirements.

How does the book address distributed systems challenges?

Chapters 5–9 tackle replication, partitioning, and consensus algorithms (e.g., Raft). Kleppmann explains trade-offs in consistency models (strong vs. eventual), explores failure modes (network partitions, leader election), and critiques solutions like two-phase commit. Real-world examples (e.g., Twitter’s feed delivery) contextualize theories.

What is the significance of batch vs. stream processing?

**Batch processing** (e.g., MapReduce) handles large datasets offline, while **stream processing** (e.g., Apache Kafka) analyzes real-time data. The book contrasts their use cases, fault-tolerance mechanisms, and integration patterns, illustrating how hybrid systems (e.g., Lambda architecture) combine both.

What are the key takeaways for designing reliable data systems?

- Prioritize **fault tolerance** through redundancy and graceful degradation. - Balance **consistency** and **availability** based on use-case needs (CAP theorem). - Use idempotent operations and transactional guarantees to handle race conditions.

How does Kleppmann approach data storage and retrieval?

Chapter 3 compares storage engines like **LSM-trees** (write-optimized, used in Cassandra) and **B-trees** (read-optimized, common in PostgreSQL). It explains how indexing, compression, and memory hierarchies impact performance, helping readers optimize for read/write patterns.

Conception d’applications de données intensives

Les grandes idées derrière les systèmes fiables, évolutifs et maintenables

Martin Kleppmann

4.7(10084 Reviews)

Technology

Aperçu de Conception d’applications de données intensives

La bible de l'ingénierie des données moderne qui a transformé la façon dont les géants de la tech conçoivent leurs systèmes. Agrémenté de cartes dignes de l'univers de Tolkien et recommandé par le fondateur de Databricks, Matei Zaharia, ce guide révèle pourquoi les principes fondamentaux des plateformes aux milliards d'utilisateurs n'ont pas changé depuis des décennies.

Choisissez la façon de le raconter

Un livre. De nombreuses façons de l'écouter.

Les mêmes idées de Conception d’applications de données intensives. Choisissez la voix, la profondeur et le rythme qui vous conviennent. Changez à tout moment.

Chapitre 1

The Database Revolution: Transforming Data into Insights

Ever wondered why tech giants like Amazon and Google can process billions of data points in milliseconds while your laptop struggles with a modest spreadsheet? The secret lies in the architecture of data-intensive applications-systems designed to prioritize data over computation. Martin Kleppmann's "Designing Data-Intensive Applications" has become the bible for engineers tackling these challenges, selling over 500,000 copies since its 2017 release and earning praise from Elon Musk who called it "required reading for anyone building modern software systems." This comprehensive guide demystifies the principles behind reliable, scalable, and maintainable data systems, offering a roadmap through the increasingly complex landscape of databases, distributed systems, and data processing frameworks.

Chapitre 2

The Three Pillars: Reliability, Scalability, and Maintainability

At the heart of any data system lie three fundamental concerns that determine its success or failure. Understanding these pillars provides the foundation for everything that follows. Reliability means a system continues working correctly even when things go wrong. Unlike failures (when the entire system stops providing service), faults are components deviating from their specifications. Since eliminating all faults is impossible, well-designed systems incorporate fault-tolerance mechanisms. These systems must handle hardware failures (disk crashes, RAM faults, power outages), software errors (bugs that trigger under unusual circumstances), and human mistakes (configuration errors, which actually cause more outages than hardware failures). The counterintuitive approach of deliberately triggering faults-like Netflix's Chaos Monkey randomly killing processes-builds confidence in fault-handling mechanisms. As one engineer put it: "The only thing worse than a system failing is a system that fails silently." Scalability describes a system's ability to handle increased load, whether that's more users, more data, or more complexity. Rather than being a one-dimensional label ("this database is scalable"), it requires specific questions about how the system responds to particular growth patterns. Twitter provides an excellent case study: while handling 4,600 tweets per second seems straightforward, the real challenge comes from fan-out-each tweet must be delivered to followers' timelines. This forced Twitter to switch from querying tweets at read time to precomputing timelines at write time. When measuring performance under load, percentiles provide much better insight than averages. While the median (50th percentile) shows typical performance, higher percentiles (p95, p99, p999) reveal how bad the outliers are. These tail latencies directly impact user experience, especially for valuable customers with complex accounts who often experience the slowest performance. Maintainability ensures future engineers can work productively on the system. This requires good operability (making systems easy for operations teams to manage), simplicity (reducing complexity so engineers can understand the system), and evolvability (making systems easy to modify for unanticipated use cases). As systems grow, they often accumulate "accidental complexity"-complexity not inherent to the problem itself but resulting from the implementation. Good abstractions can hide this complexity behind clean interfaces, though finding good abstractions remains extremely challenging.

Voyez chaque mot au fil de l'écoute

Suivez facilement la lecture tandis que chaque mot de Conception d’applications de données intensives s'illumine en temps réel.

Chapitre 3

Data Models and Storage: The Foundation of Everything

The way we represent data fundamentally shapes how we think about our problems and architect solutions. Most applications layer multiple data models on another, creating a complex hierarchy from high-level application objects down to raw bytes on disk. Each layer serves as an abstraction, hiding complexity from the layers above it while providing a clean interface for interaction. The relational model, pioneered by Edgar Codd in 1970, has dominated database technology for decades. Its strength lies in its mathematical foundation and ability to represent complex relationships through tables and foreign keys. Initially designed for business data processing, it has proven remarkably versatile, successfully handling everything from financial transactions to social networks. The SQL language that accompanies relational databases has become a lingua franca for data manipulation. Document databases like MongoDB and CouchDB have gained significant traction, particularly in web applications. They excel by offering better data locality - storing related information together in a single document - and providing flexible schemas that can evolve with application needs. This approach maps naturally to object-oriented programming paradigms and can simplify application code when data has a hierarchical structure. When comparing these models, several critical considerations emerge: • Schema flexibility: Document models allow different records to have different fields, while relational models enforce a strict schema • Query capabilities: Relational databases excel at joins and complex queries across tables • Data integrity: Relational databases provide stronger guarantees through ACID properties • Performance characteristics: Document databases often provide better performance for simple queries on hierarchical data • Development velocity: Document models can enable faster iteration during early development phases The storage engine layer beneath these data models plays a crucial role in performance and efficiency. Log-structured merge trees (LSM-trees), used in systems like Cassandra, LevelDB, and RocksDB, treat the database as an append-only log. They optimize write performance by sequentially writing data and periodically merging and compacting files to reclaim space. This approach particularly suits write-heavy workloads and offers efficient space utilization through compression. B-trees, the backbone of most relational databases like PostgreSQL and MySQL, take a different approach. They maintain a balanced tree structure and update pages in place, providing consistent read performance across the entire dataset. While B-trees typically offer faster reads and simpler recovery, LSM-trees generally provide better write throughput and compression. The choice between storage engines often depends on specific workload characteristics: • Read/write ratio • Working set size versus available memory • Required latency consistency • Backup and recovery requirements • Compression importance As noted by Martin Kleppmann: "The difference between a good database and a bad one often comes down to whether its storage engine matches your workload. Understanding these fundamentals helps you make better architectural decisions."

Chapitre 4

The Distributed Revolution: Beyond Single Machines

When data grows beyond what a single machine can handle, we enter the world of distributed systems, where everything becomes significantly more complex. This transition typically occurs when dealing with datasets in the terabyte range or when handling thousands of operations per second. Two main techniques allow us to spread data across multiple machines: replication (keeping copies of the same data on multiple nodes) and partitioning (splitting data into subsets). Replication provides redundancy in case nodes fail, keeps data geographically close to users, and allows scaling read throughput. For example, Netflix uses replication to store copies of movies across different continents, ensuring smooth streaming regardless of viewer location. Three main approaches exist: single-leader replication (writes go to one node, then propagate to followers), multi-leader replication (writes accepted at multiple nodes), and leaderless replication (writes go directly to multiple replicas). Each approach involves fundamental trade-offs. Single-leader replication, used by traditional databases like PostgreSQL, is simple to understand but creates a bottleneck at the leader. Multi-leader and leaderless approaches offer better write scalability and resilience to node failures but introduce complex conflict resolution problems when the same data is modified in multiple places simultaneously. Amazon's Dynamo database pioneered the leaderless approach, influencing many modern distributed databases like Cassandra and Riak. Partitioning (or sharding) splits data across many machines, allowing truly massive datasets and query throughput. Facebook, for instance, partitions user data across thousands of servers based on user ID. The key challenge is deciding how to partition data to spread the load evenly. Two main approaches exist: partitioning by key range (like encyclopedia volumes) and partitioning by hash of key (which distributes data more evenly but loses the ability to do efficient range queries). As systems scale, they must handle rebalancing (moving data between nodes when adding or removing machines) and request routing (determining which node handles which request). These operations become particularly challenging during node failures or network problems. Google's Spanner database, for example, uses atomic clocks to maintain consistency across global data centers, while Apache Cassandra uses consistent hashing to minimize data movement during rebalancing. The complexity of distributed systems introduces numerous failure modes that don't exist in single-machine systems. Network partitions, clock synchronization issues, and partial failures become daily operational concerns. As Kleppmann writes, "In distributed systems, suspicion, pessimism, and paranoia pay off." This mindset has led to the development of sophisticated consensus protocols like Paxos and Raft, which ensure system reliability even when multiple things go wrong simultaneously. Modern distributed systems often combine multiple approaches - for instance, using partitioning for scalability while implementing multi-region replication for disaster recovery. This hybrid approach is exemplified by systems like Google's Bigtable and Amazon's Aurora, which provide both horizontal scalability and strong consistency guarantees.

Profitez davantage de Conception d’applications de données intensives

Recevez des idées chaque jour parmi plus de 100 000 leçons
Les mots s'illuminent au rythme de l'audio
Votre bibliothèque sauvegardée sur tous vos appareils

Chapitre 5

The Consistency Conundrum: Transactions and Consensus

Transactions have been the traditional approach to handling errors in databases, grouping operations into units that either completely succeed or completely fail. The familiar ACID properties (Atomicity, Consistency, Isolation, Durability) aim to provide a simple programming model despite concurrent access and potential failures. Atomicity ensures that partial failures don't leave data in an inconsistent state, while durability guarantees that committed changes survive system crashes. These properties become especially critical in financial systems, inventory management, and other domains where data integrity is paramount. However, these properties are often misunderstood and their implementation varies significantly across database systems. Isolation levels like "read committed" and "serializable" represent different trade-offs between consistency and performance. Many databases default to weaker isolation levels that can lead to subtle bugs like lost updates, write skew, and phantom reads. For example, in a banking application, concurrent transactions might lead to incorrect balance calculations if proper isolation isn't maintained. Write skew can occur in scheduling systems where two users might book the same time slot simultaneously, while phantom reads can affect reporting queries by showing inconsistent results. Three main approaches to implementing serializability exist, each with distinct characteristics. Actual serial execution (running transactions one at a time) provides the strongest guarantees but limits throughput, making it suitable only for specific use cases with low concurrency requirements. Two-phase locking (making readers and writers block each other) offers better concurrency but can lead to deadlocks and reduced performance under high contention. Serializable snapshot isolation (optimistically allowing concurrent execution but checking for conflicts at commit time) provides good performance for read-heavy workloads but may require transactions to abort and retry when conflicts are detected. The challenges multiply exponentially in distributed systems where network delays and partial failures are inevitable. The CAP theorem states that when a network partition occurs, a system must choose between consistency (linearizability) and availability. This leads to a spectrum of consistency models from strong consistency (which sacrifices availability during network problems) to eventual consistency (which remains available but may temporarily return stale data). Real-world systems like Amazon's Dynamo DB and Google's Spanner implement different points along this spectrum, each making different trade-offs based on their specific requirements. Consensus-getting all nodes to agree on something-proves surprisingly difficult in distributed systems, particularly in the presence of node failures and network partitions. Algorithms like Paxos and Raft solve this problem but require careful implementation and consideration of failure scenarios. Modern implementations like etcd and ZooKeeper provide practical solutions but must handle complex edge cases like split-brain scenarios and leader election. As Kleppmann notes, "Many system failures occur in the gap between theoretical models and practical implementations," highlighting the importance of thorough testing and monitoring in distributed systems. The complexity of these systems has led to the development of new approaches like CRDTs (Conflict-free Replicated Data Types) and causal consistency models, which attempt to provide stronger guarantees while maintaining availability. These approaches recognize that different applications have different consistency requirements and that one size doesn't fit all when it comes to distributed data management.

Chapitre 6

Processing Paradigms: Batch and Stream

Modern data systems often combine multiple processing paradigms to handle different aspects of data transformation. Batch processing, exemplified by MapReduce and its successors, excels at processing large volumes of historical data with high throughput. Stream processing handles unbounded, continuously arriving data with lower latency. Each paradigm offers distinct advantages and serves specific use cases in data architecture. Batch processing follows the Unix philosophy of immutable inputs and outputs, with each stage transforming data without side effects. This approach makes systems easier to understand, debug, and maintain. The batch paradigm operates on fixed-size data sets, processing them in discrete chunks. For example, a retail company might run nightly batch jobs to analyze sales data, update inventory levels, and generate reports. Modern dataflow engines like Spark and Flink extend these principles with more flexible processing models and better performance, offering features like in-memory processing and iterative algorithms. These systems can process terabytes of data efficiently, making them ideal for complex analytics and machine learning workloads. Stream processing addresses scenarios where data arrives continuously and requires immediate handling. Applications include fraud detection in financial transactions, real-time monitoring of IoT sensor networks, and maintaining materialized views for user-facing applications. For instance, a social media platform might use stream processing to update trending topics every few seconds based on incoming posts. The key challenges include handling time (distinguishing between event time and processing time), managing state across long-running computations, and ensuring fault tolerance. Systems must deal with late-arriving data, out-of-order events, and varying processing speeds. The lambda architecture combines batch and stream processing, using a fast stream processor for approximate real-time results and a batch processor for correct but delayed results. For example, an e-commerce recommendation system might use streaming to provide instant personalized suggestions while using batch processing to build more accurate long-term user profiles. However, newer systems unify these approaches, allowing the same code to process both historical and real-time data. Technologies like Apache Flink's Table API and Spark Structured Streaming enable developers to write single applications that handle both batch and stream processing seamlessly. Modern architectures often employ hybrid approaches, selecting the appropriate processing paradigm based on specific requirements. For instance, a financial system might use stream processing for real-time fraud detection while relying on batch processing for end-of-day reconciliation and regulatory reporting. This flexibility allows organizations to balance the trade-offs between latency, throughput, and complexity while meeting their business needs.

Voyez chaque mot au fil de l'écoute

Suivez facilement la lecture tandis que chaque mot de Conception d’applications de données intensives s'illumine en temps réel.

Chapitre 7

Building Data Systems for the Future

The proliferation of specialized data tools creates a fundamental challenge in modern system design: no single tool can optimally serve all use cases, forcing organizations to combine multiple systems. This integration becomes more manageable when we think in terms of derived data-treating one dataset as the authoritative source of truth and others as derived views. For example, a company might maintain customer records in a relational database while using a search engine for fast text queries and a cache for rapid access to frequently requested data. Change data capture (CDC) and event sourcing provide robust mechanisms for propagating changes between systems. CDC tracks modifications in the primary database and broadcasts these changes as events, while event sourcing captures all state changes as an immutable sequence of events. For instance, an e-commerce platform might use CDC to automatically update its search index whenever product details change in the main database, or employ event sourcing to maintain a complete history of order processing steps. By treating data changes themselves as a stream of events, we can maintain multiple representations optimized for different access patterns-such as real-time dashboards, analytical databases, and caching layers. The unbundling of database functionality represents a significant shift from traditional architectures. Instead of forcing a single database to handle everything from ACID transactions to full-text search, modern systems compose specialized tools that excel at specific tasks. A typical setup might combine PostgreSQL for transactional data, Elasticsearch for text search, Redis for caching, and Apache Kafka for event streaming. These components cooperate through well-defined interfaces, allowing each to focus on its strengths while contributing to a more flexible and scalable system. However, this distributed approach introduces new challenges around consistency and coordination. Systems must handle network delays, partial failures, and eventual consistency. End-to-end correctness often requires sophisticated application-specific mechanisms. These include operation identifiers for ensuring idempotence (preventing duplicate processing), careful ordering of events, and asynchronous constraint checking across system boundaries. For example, a distributed e-commerce system might need to implement its own mechanisms to ensure that stock levels remain accurate across multiple services, or that customer loyalty points are consistently updated across different systems. As Martin Kleppmann astutely observes, "Even with the strongest safety guarantees, applications must implement their own end-to-end measures." This reality requires developers to carefully consider failure modes, implement retry mechanisms, and design systems that can recover from inconsistencies. Success in this environment demands a deep understanding of both the capabilities and limitations of each component, as well as the interaction patterns between them.

Chapitre 8

Ethics and Responsibility in the Data Age

As engineers building data systems, we must consider their broader impacts. Predictive analytics can both help and harm-algorithms making decisions about loans, insurance, or criminal justice can systematically exclude individuals without due process. These systems often amplify existing biases rather than eliminating them. For example, lending algorithms trained on historical data may perpetuate decades of redlining practices, while facial recognition systems have shown significantly higher error rates for minorities and women. Privacy concerns become increasingly important as we collect more data. The surveillance infrastructure we've built would have been unimaginable to previous generations. Every smartphone click, credit card purchase, and social media interaction creates digital breadcrumbs that can be assembled into detailed portraits of our lives. As Bruce Schneier notes, "Data is the pollution problem of the information age, and protecting privacy is the environmental challenge." Companies now possess intimate knowledge of our shopping habits, health concerns, political views, and social connections - often without explicit consent. Just as the Industrial Revolution eventually required environmental regulations and workplace safety standards, the Information Age needs frameworks to ensure data is collected and used responsibly. This includes giving individuals control over their data, being transparent about how data is used, and designing systems that respect human dignity and agency. Key principles should include: • Data minimization: Only collecting what's necessary for specific purposes • Purpose limitation: Using data only for declared purposes • Individual access rights: Allowing people to view, correct, and delete their data • Algorithmic accountability: Regular audits of automated decision systems • Privacy by design: Building protection into systems from the start The European Union's GDPR represents an early attempt at comprehensive data protection regulation, but much work remains. Engineers must proactively consider ethical implications during system design, not as an afterthought. This includes careful consideration of potential misuse cases, regular bias testing, and clear processes for addressing harmful outcomes. Building ethical data systems requires ongoing collaboration between technologists, policymakers, ethicists, and the communities affected by these technologies. We must also recognize that privacy and fairness often involve tradeoffs. More data can lead to better services but increases privacy risks. Automated decisions can be more consistent but may lack human judgment and empathy. Finding the right balance requires careful consideration of context and values.

Profitez davantage de Conception d’applications de données intensives

Recevez des idées chaque jour parmi plus de 100 000 leçons
Les mots s'illuminent au rythme de l'audio
Votre bibliothèque sauvegardée sur tous vos appareils

Chapitre 9

The Path Forward: Simplicity, Resilience, and Humanity

Building reliable data systems requires both technical excellence and ethical awareness. The most successful systems combine specialized components with clear boundaries, maintain derived data through well-defined transformations, and incorporate end-to-end correctness checks. These systems embrace patterns like event sourcing for audit trails, CQRS for separating read and write concerns, and idempotency for reliable message processing. Key architectural principles include designing for failure, implementing clear consistency boundaries, and maintaining system observability. For example, successful systems often implement circuit breakers to prevent cascade failures, use bulkheading to isolate critical components, and maintain comprehensive monitoring and alerting systems. They also incorporate patterns like sagas for managing distributed transactions and outbox patterns for reliable message publishing. As data volumes and complexity continue to grow, the principles of simplicity, resilience, and human-centered design become ever more important. Simple systems are easier to understand, maintain, and debug. This might mean choosing a straightforward relational database over a more complex NoSQL solution when possible, or implementing clear domain boundaries rather than allowing unconstrained data access. Resilience requires both technical robustness and operational excellence - including comprehensive backup strategies, disaster recovery plans, and well-documented operational procedures. Human-centered design considerations extend beyond user interfaces to include system operability, clear error messages, and comprehensive documentation. Systems should be designed with the needs of operators, developers, and end-users in mind. This includes providing clear monitoring dashboards, implementing gradual rollout capabilities, and maintaining detailed audit logs for troubleshooting. The future belongs to systems that embrace the messy reality of distributed computing while providing abstractions that make this complexity manageable. This means implementing patterns like event-driven architectures that handle eventual consistency gracefully, designing systems that can scale horizontally while maintaining data integrity, and building in observability from the ground up. Successful systems often combine multiple paradigms - such as using both synchronous and asynchronous communication patterns where appropriate, or mixing strong and eventual consistency models based on business requirements. As Kleppmann concludes, "Good abstractions allow us to build more complex systems than we otherwise could-and ultimately, that's what engineering is all about." This means creating layers of abstraction that hide unnecessary complexity while exposing the right controls and visibility for effective operation and maintenance. The most successful systems strike a balance between powerful capabilities and operational simplicity, enabling organizations to build and maintain robust data systems at scale.

★★★★★

Vous êtes arrivé au bout de Conception d’applications de données intensives

Adopté par plus d'un million d'apprenants

“Cela fait 23 jours et je l'utilise tous les jours. Cette application fait désormais partie de ma routine.”

jayallen

Thèmes clés dans Conception d’applications de données intensives

distributed systems architecture
data storage engines
system scalability patterns
fault tolerance design
data modeling trade-offs

Citations de Conception d’applications de données intensives

Data-intensive applications are distinguished from traditional applications by the fact that data volume, data complexity, and data velocity are significant.
Reliability means making systems work correctly, even when faults occur.
Scalability is the term we use to describe a system’s ability to cope with increased load.

Personnages de Conception d’applications de données intensives

Martin KleppmannAuthor and expert in data-intensive applications
Edgar CoddPioneer of the relational data model

À propos de l'auteur

Martin Kleppmann, auteur du best-seller Designing Data-Intensive Applications, est une autorité de premier plan dans le domaine des systèmes distribués et de l'architecture de données évolutive. Chercheur à l'Université technique de Munich et professeur associé à l'Université de Cambridge, Kleppmann fait le pont entre la rigueur académique et l'expertise concrète issue de sa carrière dans la Silicon Valley, où il a cofondé des startups et conçu l'infrastructure de données de LinkedIn. Son livre, salué pour sa clarification de sujets complexes tels que les modèles de cohérence et la conception cloud-native, est devenu une ressource fondamentale pour les ingénieurs logiciels et les architectes depuis sa publication en 2017.

Kleppmann fait progresser activement la recherche sur les systèmes distribués grâce à des collaborations avec le laboratoire Ink & Switch et des interventions lors de conférences majeures telles que QCon et ECOOP. Il tient un blog technique et gère des projets open-source comme Automerge, explorant les types de données répliquées sans conflit (CRDT) pour les logiciels « local-first ». Avec des milliers d'avis cinq étoiles, Designing Data-Intensive Applications est largement recommandé dans les communautés technologiques et les programmes universitaires, consolidant son statut de classique moderne de la littérature informatique.

Telecharger le resume de Conception d’applications de données intensives

Obtenez le resume de Conception d’applications de données intensives en PDF ou EPUB gratuit. Imprimez-le ou lisez-le hors ligne a tout moment.

Les utilisateurs ont aussi aimé

Clean Architecture

Robert C. Martin

Architecting for Scale

Lee Atchison

Algorithms + Data Structures

Niklaus Wirth

Couverture du livre System design is more than just picking tools

23 sources

System design is more than just picking tools

Clean Code

Robert C. Martin

Building Microservices

Sam Newman

System Design Interview

Alex Xu

Big Data

Viktor Mayer-Schönberger & Kenneth Cukier

FAQ sur ce livre

Fait partie d'un plan d'apprentissage

PLAN D'APPRENTISSAGE

Python, IA, réseau & serveur local maison

5 h 15 m•4 Épisodes

Découvrir plus

PLAN D'APPRENTISSAGE

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 Sections

PLAN D'APPRENTISSAGE

From Data Scripts to AI Systems

This plan is essential for data scientists and engineers looking to move beyond basic modeling into high-level system design. It provides the deep architectural knowledge needed to understand how modern AI actually processes information and scales in production environments.

1 h 30 m•3 Sections

PLAN D'APPRENTISSAGE

Deep Dive: AI Architecture & Model Training

This comprehensive path is essential for engineers and data scientists looking to move beyond basic scripts into architectural design. It provides the technical depth needed to build, optimize, and scale robust AI systems in professional environments.

4 h 46 m•4 Sections

PLAN D'APPRENTISSAGE

The Data Science Engine

In an increasingly data-driven economy, understanding the end-to-end lifecycle of information is a critical competitive advantage. This plan is ideal for aspiring data professionals and managers who need to bridge the gap between technical execution and ethical leadership.

2 h•4 Sections

PLAN D'APPRENTISSAGE

become a data scientist

This comprehensive plan bridges the gap between theoretical statistics and practical production-level engineering. It is ideal for aspiring data scientists and analysts looking to transition into high-impact roles by mastering the full lifecycle of data-driven decision making.

5 h 35 m•4 Sections

PLAN D'APPRENTISSAGE

design！

This comprehensive design learning path is essential for anyone looking to build or elevate their design career in today's innovation-driven landscape. It's ideal for aspiring designers seeking structured skill development, product managers wanting to think more like designers, entrepreneurs needing to create user-centered solutions, and experienced designers aiming to reach strategic leadership levels. The curriculum bridges foundational knowledge with cutting-edge practice, ensuring you're prepared for both current design challenges and future AI-integrated workflows.

4 h 29 m•4 Sections

PLAN D'APPRENTISSAGE

Architecting for Scale: The Interview Playbook

This playbook is essential for software engineers aiming for senior or staff-level roles at top-tier tech companies. It provides a structured methodology to tackle the high-pressure system design interview by focusing on data scalability and the art of the trade-off.

1 h 30 m•3 Sections

PLAN D'APPRENTISSAGE

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 Sections

Cree par des anciens de Columbia University a San Francisco

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

Decouvrez comment BeFreed est discute sur le web

Cree par des anciens de Columbia University a San Francisco

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

Decouvrez comment BeFreed est discute sur le web

Commencez votre parcours d'apprentissage, maintenant

Chapitre 5

Conception d’applications de données intensives

AperçuAperçu de Conception d’applications de données intensives

Un livre. De nombreuses façons de l'écouter.

The Database Revolution: Transforming Data into Insights

The Three Pillars: Reliability, Scalability, and Maintainability

Voyez chaque mot au fil de l'écoute

Data Models and Storage: The Foundation of Everything

The Distributed Revolution: Beyond Single Machines

Profitez davantage de Conception d’applications de données intensives

The Consistency Conundrum: Transactions and Consensus

Processing Paradigms: Batch and Stream

Voyez chaque mot au fil de l'écoute

Building Data Systems for the Future

Ethics and Responsibility in the Data Age

Profitez davantage de Conception d’applications de données intensives

The Path Forward: Simplicity, Resilience, and Humanity

Vous êtes arrivé au bout de Conception d’applications de données intensives

Thèmes clés dans Conception d’applications de données intensives

Citations de Conception d’applications de données intensives

Personnages de Conception d’applications de données intensives

À propos de l'auteur

Telecharger le resume de Conception d’applications de données intensives

Les utilisateurs ont aussi aimé

FAQ sur ce livre

What is Designing Data-Intensive Applications by Martin Kleppmann about?

Who should read Designing Data-Intensive Applications?

Is Designing Data-Intensive Applications worth reading?

What data models are discussed in Designing Data-Intensive Applications?

Fait partie d'un plan d'apprentissage

Python, IA, réseau & serveur local maison

Découvrir plus

1,000,000+ curious minds.

1,000,000+ curious minds.

Un livre. De nombreuses façons de l'écouter.

The Database Revolution: Transforming Data into Insights

The Three Pillars: Reliability, Scalability, and Maintainability

Voyez chaque mot au fil de l'écoute

Data Models and Storage: The Foundation of Everything

The Distributed Revolution: Beyond Single Machines

Profitez davantage de Conception d’applications de données intensives

The Consistency Conundrum: Transactions and Consensus

Processing Paradigms: Batch and Stream

Voyez chaque mot au fil de l'écoute

Building Data Systems for the Future

Ethics and Responsibility in the Data Age

Profitez davantage de Conception d’applications de données intensives

The Path Forward: Simplicity, Resilience, and Humanity

Vous êtes arrivé au bout de Conception d’applications de données intensives

Les utilisateurs ont aussi aimé

Fait partie d'un plan d'apprentissage

Python, IA, réseau & serveur local maison

Découvrir plus

Aperçu de Conception d’applications de données intensives