What is *Architecting for Scale* by Lee Atchison about?

*Architecting for Scale* provides actionable strategies for building scalable, high-availability systems in cloud environments. It focuses on modern architectures like microservices, risk mitigation, and organizational alignment through frameworks like the Single Team Owned Service Architecture (STOSA). The book emphasizes maintaining performance during rapid growth, leveraging cloud resources, and balancing scalability with reliability.

Who should read *Architecting for Scale*?

This book targets technical leaders, architects, and managers in engineering/operations roles handling large-scale applications. It’s particularly valuable for teams transitioning to cloud-native or microservices architectures. Lee Atchison’s 32-year experience, including seven years at Amazon and AWS, lends authority to its practical insights.

Is *Architecting for Scale* worth reading?

Yes, for those seeking a roadmap to scalable systems. It offers actionable tips on risk management, cloud optimization, and team structuring. However, critics note it’s less detailed on advanced DevOps/SRE practices, making it better suited for foundational knowledge than niche technical deep dives.

What is the STOSA model in *Architecting for Scale*?

The **Single Team Owned Service Architecture (STOSA)** paradigm ensures each microservice is managed by a dedicated team, reducing bottlenecks and aligning development with operational scalability. This model promotes autonomy, accelerates iteration, and simplifies dependency management in large organizations.

How does *Architecting for Scale* approach risk management?

The book introduces a **Risk Matrix** to quantify and prioritize system vulnerabilities. By evaluating factors like outage likelihood and customer impact, teams can allocate resources to mitigate critical risks first. A free Excel template is provided for practical implementation.

What are key principles for cloud scalability in the book?

Atchison advocates for auto-scaling, stateless services, and distributed databases to handle traffic spikes. He stresses designing for elasticity (scaling up/down dynamically) and using managed cloud services (e.g., AWS Lambda) to reduce operational overhead.

How does *Architecting for Scale* measure service availability?

Availability is tracked via **SLAs (Service-Level Agreements)** and **SLOs (Service-Level Objectives)**, with metrics like uptime percentage and error rates. The book highlights balancing strict SLAs with engineering costs to avoid over-optimization.

Does *Architecting for Scale* cover microservices?

Yes, it details transitioning monolithic systems to microservices, emphasizing decoupled services, API gateways, and decentralized data management. The book also addresses organizational challenges, like aligning teams with service ownership.

확장 가능한 시스템 설계기법

성장하는 애플리케이션을 위한 고가용성

리 애치슨

3.57(228 Reviews)

확장 가능한 시스템 설계기법 개요

"Architecting for Scale"에서 리 애치슨(Lee Atchison)은 고성능 성장 애플리케이션을 위한 기술 업계의 생존 가이드를 제시합니다. Shopify의 부사장 콜린 보델(Colin Bodell)이 추천한 이 청사진은 혼란스러운 시스템을 회복 탄력성이 있는 아키텍처로 변화시킵니다. 아마존 베테랑들은 알고 있지만 대부분의 엔지니어들은 모르는 스케일링의 비밀은 무엇일까요?

전달 방식을 선택하세요

한 권의 책, 다양한 듣기 방식.

확장 가능한 시스템 설계기법의 같은 아이디어를 담았습니다. 나에게 맞는 목소리, 깊이, 속도를 고르고 언제든 바꿔 보세요.

1장

When Scaling Becomes the Silent Killer of Your Business

Have you ever wondered why tech giants like Amazon and Netflix seem to operate flawlessly despite serving millions of users simultaneously, while other promising startups collapse under the weight of their own success? "Architecting for Scale" by Lee Atchison has become the secret weapon for engineering leaders navigating the treacherous waters of application growth. Since its publication, this book has influenced countless tech organizations, with companies like Uber, Airbnb, and Spotify implementing its principles to maintain stability during explosive growth. The book's practical approach to managing risk while scaling has made it required reading at top engineering schools and a favorite recommendation among CTOs. What makes this work particularly valuable is how it transforms complex technical concepts into actionable strategies that bridge the gap between business needs and technical implementation-a rare quality that explains why it remains one of the most highlighted technical books on Kindle.

2장

The Existential Threat of Poor Availability

In today's digital landscape, your software isn't just part of your customer experience-it often IS the entire customer experience. When applications fail, customers don't see temporary technical difficulties; they see a broken brand promise. Imagine hosting friends for a major sporting event, only to have your power cut right before the winning play. That's exactly how customers feel when your service goes down during their critical moments. This reality creates an existential business question: Why would customers choose you if your service isn't operational when they need it? What impression does your brand make when customers encounter error messages instead of solutions? The correlation between system availability and customer satisfaction isn't just strong-it's absolute. Availability issues typically emerge from several predictable sources: resource exhaustion as user numbers grow, hasty changes implemented under pressure, increasing complexity as more developers contribute to the codebase, dependencies on external services that may fail, and accumulating technical debt. These problems can appear gradually or strike suddenly, but all fast-growing applications eventually face them. While reliability (providing correct answers) and availability (providing timely responses) are related concepts, availability problems are typically harder to solve. You can test for reliability, but maintaining availability under unpredictable conditions requires architectural foresight. This is why building for scale means, fundamentally, building for high availability.

들리는 모든 단어를 눈으로 확인하세요

확장 가능한 시스템 설계기법의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

3장

Flying Two Mistakes High: The Margin for Error

A radio-controlled airplane pilot once shared a crucial principle with Atchison: always fly "two mistakes high." This means maintaining enough altitude that if you make a mistake and lose altitude, you still have enough height to recover from a potential second mistake during the stressful recovery process. This principle applies perfectly to application architecture. Consider a service handling 1,000 requests per second with servers that can each process 300 requests per second. Basic math suggests you need four servers. But what happens when one fails? The remaining three would need to handle 333 requests per second each-exceeding their capacity and causing cascading failures. To truly handle a single node failure, you actually need five servers, ensuring the remaining four can still manage the load at 250 requests per second each. But even this isn't enough for real-world operations. During a rolling deployment, one node will be offline for upgrading. If another node fails during this process (not an uncommon scenario), you'd be down to just three nodes-insufficient for your traffic. To be genuinely "two mistakes high," you need six servers. This principle becomes even more complex when considering data center redundancy. Counterintuitively, distributing your application across more data centers can actually require fewer total servers while improving resilience. With four data centers and a need for 34 working servers, you need 12 servers per data center (48 total) to guarantee sufficient capacity if one center fails. With six data centers, you'd need only 42 total servers, while two data centers would require 68 servers-a mathematically sound but surprising conclusion. Hidden shared dependencies can undermine even careful redundancy planning. Six servers providing redundancy become useless if they're all in the same rack with a single power supply. When that power supply fails, all six go down simultaneously. These unseen common dependencies-whether physical infrastructure, network components, or software dependencies-can invalidate your redundancy plans. Perhaps most dangerous are failure loops, where a problem prevents you from implementing its solution-like storing a generator in a garage with an electric door that won't open during a power outage. In service architecture, if your deployment service fails, how do you deploy a fix? If your monitoring service fails, how do you detect other failures?

4장

The Mathematics of Uptime: Understanding Availability Metrics

Availability is typically calculated as a percentage using the formula: (total_seconds_in_period - seconds_system_is_down) / total_seconds_in_period. This seemingly simple calculation reveals how even brief outages can dramatically impact availability percentages. For example, a website experiencing just 52 minutes of downtime in a month falls short of three nines (99.9%) availability, achieving only 99.8795%. Even a mere 5-minute outage during peak business hours can have severe consequences for user trust and business operations. The industry commonly describes availability using "the nines" as shorthand, creating a logarithmic scale of reliability. Two nines (99%) allows 432 minutes of monthly downtime, equivalent to more than 7 hours of system unavailability. Three nines (99.9%) permits 43 minutes, four nines (99.99%) allows just 4 minutes, while five nines (99.999%) tolerates only 26 seconds of downtime per month. For most web applications, three nines is considered acceptable, while highly available systems like financial trading platforms or emergency services aim for five nines. Each additional nine represents an order of magnitude improvement in reliability but often comes with exponentially increasing infrastructure costs. What constitutes "reasonable" availability depends entirely on your specific application, customer expectations, and business needs. A blog platform might function adequately with two nines, while an emergency response system requires five nines. Factors to consider include peak usage periods, geographic distribution of users, regulatory requirements, and potential financial impact of outages. For instance, an e-commerce platform might need higher availability during holiday shopping seasons, while a B2B application might require peak availability during business hours but accept maintenance windows overnight. One common mistake is discounting planned maintenance when calculating availability. From the customer's perspective, whether an outage is planned or unplanned doesn't matter; if the application isn't available when needed, it creates a negative experience. An application with a weekly two-hour maintenance window can achieve at best 98.8% availability-not even reaching two nines (99%). This reality has driven many organizations toward zero-downtime deployment strategies and rolling updates. Modern cloud architectures often implement blue-green deployments or canary releases to maintain service availability during updates. When establishing availability targets, it's crucial to consider the complete system architecture, including dependencies. A service might aim for four nines, but if it relies on three external services each with three nines availability, the compound availability will be significantly lower. This cascading effect, known as the multiplication of probabilities, means that achieving high availability requires careful attention to every component in the system stack.

확장 가능한 시스템 설계기법에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

5장

Reversing the Availability Death Spiral

Even stable systems can experience a gradual decline in availability. What begins as an isolated outage can quickly cascade into a pattern of failures that attracts unwanted attention from customers, sales teams, and executives. When availability begins to slip, immediate action is necessary. The first step is establishing measurement. Track when your application is available and unavailable to calculate percentage metrics over time. Continuously monitor these metrics and overlay key system events to identify correlations between changes and availability issues. Implement service tiers to distinguish between mission-critical and non-essential services, and maintain a risk matrix to track technical debt. Next, automate your manual processes. Manual operations introduce variables and unknowns that threaten high availability-you should never perform manual operations on production systems. Automated, repeatable processes allow you to test changes before implementation, have changes reviewed by others, implement version control, apply changes consistently, and audit their impact. Automation enables safer experimentation. With a proper process, you can document proposed changes, have them reviewed by knowledgeable colleagues, test in staging environments, deploy quickly, and examine results immediately. If changes don't produce desired results, you can quickly roll back to a known good state. Automated sanity testing for all changes provides another layer of protection. Using browser testing applications or tools like New Relic Synthetics, you can simulate customer interactions with your application. Your deployment system can first deploy changes to a test environment, run automated validation tests, and only proceed to production when those tests pass. Once you have monitoring, risk tracking, and safe automated changes in place, focus on improving your application's availability. Regularly review your risk matrix and recovery plans, making this part of your postmortem process. Execute projects specifically designed to mitigate identified risks, and examine how these mitigations improve availability.

6장

Five Essential Focuses for Bulletproof Availability

Building a scalable application with high availability doesn't happen automatically. To maintain availability as your system scales, you need to focus on five key areas: First, build with failure in mind. As Werner Vogels, CTO of Amazon, says, "Everything fails all the time." Implement design patterns like error catching, retry logic, and circuit breakers to limit the scope of problems. For dependencies, determine how to handle both recoverable and unrecoverable failures. Circuit breakers are particularly useful as they can "give up" on failing dependencies until recovery is confirmed. Second, always think about scaling. Build your system not for today's traffic but for tomorrow's. This means architecting for database growth, identifying and removing logical scaling limits, building applications that can easily add servers, redirecting static traffic to CDNs, and identifying supposedly dynamic content that could actually be served statically. Even content that seems dynamic (like personalized greetings) can often be mostly static with small dynamic elements added via client-side processing. Third, mitigate risk. All systems contain risks-servers crashing, databases becoming corrupted, network connections failing, or new software deployments causing issues. Maintaining availability requires risk management: identifying risks, determining acceptable risk levels, and implementing mitigations. For example, an online T-shirt store might mitigate search service failure by displaying popular products and offering discount coupons when search fails, ensuring customers can still find products. Fourth, monitor availability. You can't address problems you can't see. Implement server monitoring to track health, configuration change monitoring to identify when infrastructure changes impact your application, comprehensive visibility into both internal and external application performance through synthetic testing, and effective alerting systems. After establishing monitoring, look for performance trends and outliers that could indicate potential availability issues. Fifth, respond to availability issues in a predictable and defined way. Establish standard processes and procedures for handling common failure scenarios to decrease downtime and provide diagnostic information. When alerts trigger, service owners must be notified first, though dependent teams may also need alerts. Maintain a support manual with troubleshooting procedures and contact lists for related services.

들리는 모든 단어를 눈으로 확인하세요

확장 가능한 시스템 설계기법의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

7장

Breaking the Monolith: The Service Revolution

Modern software requires service-based architectures rather than monolithic ones to maintain availability at scale. Traditional monolithic applications contain all logic in a single component, making it difficult for multiple development teams to work without conflicts. Service-oriented architectures split applications into distinct domains managed by individual groups, enabling separation of responsibilities critical for highly scaled applications. In monolithic applications, all logic and functionality exist within a single component with intertwined code segments. This creates overlapping work areas where multiple development teams struggle with code collisions and quality issues. Service-based architectures provide clear ownership boundaries and non-overlapping responsibilities. These architectures enable more granular scaling decisions, focused team assignments, complexity localization where only service owners need to understand internal workings, and easier testing. When services have distinct owners, teams only need to understand the API contract of dependent services, not their internal complexity. A service contract includes both the capabilities (what the service does and how to call it) and the responsiveness guarantees (usage frequency, availability, and performance expectations). This service-level agreement allows teams to depend on other services without knowing their implementation details. Different application components have varying scaling needs. Service-based architectures allow scaling decisions to be made independently for each service. This enables more accurate scaling by involving knowledgeable teams, saves resources by not over-scaling components, and gives scaling ownership to the teams that best understand their service needs.

8장

Defining Service Boundaries: The Art of Decomposition

Determining what should be a service doesn't have a single correct answer. Some companies split applications into hundreds of tiny microservices, while others use only a handful of larger services. The industry is trending toward smaller microservices, facilitated by technologies like Docker and Kubernetes. Service boundaries should be determined by business requirements, team organization, data separability, and shared capabilities needs. Service boundaries can be determined using four key guidelines. First, specific business requirements like regulatory compliance, legal constraints, or security needs often dictate service boundaries. For example, credit card processing should be in its own service to handle legal/regulatory requirements, enhanced security, specialized validation, and restricted access. Second, as applications grow more complex, services help distribute ownership to different teams. A single service should be owned by one team (typically 3-8 developers) responsible for all aspects of that service. This reduces inter-team dependencies and enables independent innovation. Teams can own multiple services, but each service should have only one owning team. Third, services must maintain separate data from other services. Having multiple independent code bases operating on the same data creates problems. Services should only access another service's data through its API, never directly. This separation is crucial when determining service boundaries-if it makes sense for a service to "own" its data and provide access only through interfaces, it's a good candidate for a service boundary. Fourth, services can be created to provide shared capabilities and data needed by multiple other services. A user identity service is a prime example, providing information about system users to many other services. Such centralized services that manage common data are highly useful even if they don't contain complex business logic. While service-based architectures have benefits, creating too many services can be problematic. Breaking down a simple service like user identity into ultra-granular services (name service, address service, email service, etc.) usually goes too far. Each service split decreases individual service complexity but increases overall application complexity. Finding the proper balance between too few and too many services is challenging and depends on your specific application, organization, and company culture.

확장 가능한 시스템 설계기법에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

9장

Managing Data in a Service Architecture

When building or migrating to a service-based architecture, it's critically important to be mindful of where data and state are stored within your application. Stateless services-those that manage no data or state of their own-offer huge scaling advantages, as it's easy to add server capacity both vertically and horizontally. While not all services can be stateless, those that can gain tremendous scalability advantages. For example, a product catalog service that only reads data can be easily replicated across multiple servers, while a shopping cart service necessarily maintains state and requires more careful scaling considerations. Rather than centralizing data storage, you should localize data as much as possible. Each service should manage only the data it needs and be considered the single source of truth for that data. This functional partitioning provides several benefits: reduced size of individual datasets making database scaling easier, localized access that reduces unnecessary data retrieval, and the ability to optimize access methods by selecting the right type of data store for each specific dataset. For instance, a user profile service might use a document store like MongoDB, while a product inventory service might use a traditional relational database, and a caching service might employ Redis. Data partitioning splits datasets into segments based on some key within the data, often to utilize multiple databases for handling larger datasets or higher access frequencies. Common partitioning strategies include range-based (e.g., dates, alphabetical ranges), hash-based (computing a hash of the key), and geographic-based partitioning. While useful, data partitioning introduces several challenges: increased application complexity, difficulty with cross-partition queries, risk of skewed partition usage if the wrong key is chosen, and the potentially difficult task of repartitioning. Account-based keys are typically problematic as accounts can grow unevenly, causing some partitions to become overloaded. When implementing data partitioning, consider implementing a routing layer that abstracts the complexity of partition location from your services. This can be achieved through tools like proxy services or specialized middleware. It's also crucial to implement proper monitoring and alerting for partition health, including metrics for partition size, query performance, and load distribution. Regular rebalancing may be necessary to maintain optimal performance, and you should design your system to handle this process with minimal disruption to service availability. Cross-partition operations require careful consideration. Implement strategies like scatter-gather queries for operations that need to access multiple partitions, but be mindful of the performance impact. Consider maintaining secondary indexes or summary tables for frequently accessed cross-partition data. In some cases, eventual consistency models may be appropriate to improve performance while maintaining acceptable data accuracy.

10장

Graceful Degradation: The Art of Failing Well

As microservice-based applications grow, service failures become increasingly likely and potentially more impactful. When a service fails, it can trigger a chain reaction affecting all dependent services. While sometimes a dependency failure will inevitably cause your service to fail, often there are ways to prevent these cascading failures and maintain at least partial functionality. When a dependency fails, your service's response must be predictable, understandable, and reasonable for the situation. A predictable response means providing consistent behavior given specific circumstances. An error message can be a predictable response, but unpredictable responses (like returning random values) must be avoided. Don't propagate unpredictability up the value chain-even with failing dependencies, your service should respond in a planned, consistent manner. Your responses must adhere to the agreed-upon format and structure-the contract between your service and its consumers. A dependency's violation of its API contract with you never justifies breaking your own contract with your consumers. Design your interfaces to handle all contingencies, including dependency failures. When dependencies fail, your service must respond appropriately to maintain reliability. Graceful degradation means reducing functionality as little as possible when dependencies fail. For example, an ecommerce website could continue functioning without product images if the image service fails, displaying "no image available" instead of crashing the entire page. When there's insufficient data to fulfill the original request, provide alternative value instead of simply returning an error. For instance, if product details are unavailable, rather than showing an error page, display popular alternative products. This approach keeps users engaged even when their specific request can't be fulfilled. When failure is inevitable, fail immediately rather than performing unnecessary work. Check input validity upfront and abort quickly when dependencies are unavailable. This conserves resources, improves responsiveness, and provides clearer error messages. Always validate customer inputs against reasonable limits. One company's account service was crippled when a client requested 100,000 customer accounts simultaneously-far beyond any legitimate use case. The service attempted to process this unreasonable request repeatedly, consuming resources until legitimate requests began failing. Always establish and enforce service limits to prevent such resource exhaustion.

들리는 모든 단어를 눈으로 확인하세요

확장 가능한 시스템 설계기법의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

11장

The Cloud Revolution: Six Levels of Maturity

Building highly available, scaled applications requires handling variable availability demands. Traditionally, this meant over-provisioning infrastructure-if your application needs between 20-200 servers, you'd need 250 servers ready at all times to avoid scaling-related outages. As internet usage grows and becomes less predictable, static infrastructure planning becomes increasingly difficult and costly. The public cloud addresses this by enabling dynamic provisioning of resources to match current needs-scaling down during slow periods to save money and rapidly scaling up when demand exceeds expectations. A well-designed application on properly configured cloud infrastructure can handle virtually any scaling requirement, eliminating brownouts during peak usage. Cloud adoption has evolved from being used primarily by startups and progressive organizations to becoming mainstream across enterprises. However, many organizations struggle with cloud migration due to unrealistic expectations and underestimating the work involved. Companies often mistakenly view cloud migration as a simple "lift-and-shift" operation, moving existing applications to the cloud with minimal changes. True cloud success requires embracing the dynamic cloud, which enables faster scaling, quicker response to changes, and better handling of unpredictable usage patterns. Cloud maturity can be viewed as progressing through six levels: Level 1 involves experimenting with the cloud through safe, simple technologies applied to non-mission-critical applications. Organizations typically start with storage solutions like Amazon S3, avoiding the complexity of cloud-based computation. Level 2 focuses on securing the cloud as disciplines throughout the company-legal, finance, security, and others-become involved. The organization starts forming policies on cloud usage, whether formal guidelines or ad-hoc cultural understandings. Level 3 sees organizations begin replacing on-premise servers with cloud alternatives through simple lift-and-shift migrations. This level can be dangerous-organizations may bear cloud costs without enjoying corresponding benefits, potentially causing them to abandon their cloud efforts prematurely. Level 4 is where the inherent value of cloud begins emerging as organizations adopt managed services like Amazon RDS, Aurora, Azure SQL databases, Elasticsearch, Elastic Beanstalk, and ECS. These services provide capabilities while requiring less management overhead. Level 5 sees cloud-enabled organizations begin leveraging high-value services uniquely available in the cloud, such as serverless computing (AWS Lambda, Azure Functions), highly scalable databases (DynamoDB), and specialized services (SQS, SNS). Level 6 represents organizations that require cloud usage for all new applications and mandate migration of existing applications. The end goal is typically eliminating corporate data centers entirely. Cloud maturity levels apply to individual applications, organizations, or entire enterprises, with varying adoption rates. Internal applications often migrate earlier due to lower risk, potentially reaching Level 6, while complex legacy enterprise applications adopt cloud more slowly.

★★★★★

확장 가능한 시스템 설계기법 완독을 축하합니다

100만 명 이상의 학습자가 사랑합니다

“23일째 매일 사용하고 있어요. 이제 제 일상의 한 부분이 되었습니다.”

jayallen

확장 가능한 시스템 설계기법의 핵심 주제

high availability architecture
cascading failure prevention
redundancy planning
systemic risk management
application scalability

확장 가능한 시스템 설계기법의 명언

This is why building for scale means, fundamentally, building for high availability.
To be genuinely 'two mistakes high,' you need six servers.
Hidden shared dependencies can undermine even careful redundancy planning.
Availability is typically calculated as a percentage using the formula: (total_seconds_in_period - seconds_system_is_down) / total_seconds_in_period.

확장 가능한 시스템 설계기법의 등장인물

Lee AtchisonAuthor and expert in application growth

저자 소개

Architecting for Scale의 저자인 리 애치슨(Lee Atchison)은 클라우드 컴퓨팅 및 애플리케이션 현대화 분야의 저명한 사상가로, 기업 환경을 위한 고가용성 시스템 구축을 전문으로 합니다.

소프트웨어 아키텍처 문헌의 초석이 된 그의 저서는 확장 가능한 클라우드 인프라, 리스크 관리, 서비스 지향 설계 등을 다루고 있으며, 이는 Amazon, AWS, New Relic과 같은 업계 혁신 기업에서 쌓은 30년의 경력을 바탕으로 합니다. Amazon 재직 당시 그는 AWS Elastic Beanstalk을 개척했으며, 서비스 기반 아키텍처로의 중요한 마이그레이션을 주도했습니다. 현재 그는 자문 활동을 통해 조직들이 DevOps 관행과 클라우드 도입 전략을 최적화하도록 돕고 있습니다.

글로벌 기술 컨퍼런스의 단골 연사이자 InfoWorld, Forbes와 같은 매체의 기고가인 애치슨은 Modern Digital Business 팟캐스트와 후속작인 Business Breakthrough 3.0을 통해 자신의 전문성을 전파하고 있습니다. Architecting for Scale은 O’Reilly Media의 베스트셀러이자 전 세계 주요 기술 기업들이 채택한 필독서로 자리 잡으며 엔지니어링 팀의 핵심 참고서가 되었습니다.

확장 가능한 시스템 설계기법 요약 다운로드

확장 가능한 시스템 설계기법 요약을 무료 PDF 또는 EPUB으로 받으세요. 인쇄하거나 오프라인에서 언제든 읽을 수 있습니다.

다른 사용자들도 좋아한 책

Do Scale

Les McKeown

Scaling Up

Verne Harnish

Scaling People

Claire Hughes Johnson

Building Microservices

Sam Newman

Building Secure and Reliable Systems

Heather Adkins & Betsy Beyer & Paul Blankinship & Piotr Lewandowski & Ana Oprea & Adam Stubblefield

Clean Architecture

Robert C. Martin

Scale for Success

Jan Cavelle

Enterprise Architecture: Building Digital Foundations That Scale 책 표지

6 sources

Enterprise Architecture: Building Digital Foundations That Scale

이 책에 대한 FAQ

이 학습 계획의 일부

학습 계획

더 알아보기

학습 계획

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 섹션

학습 계획

Architecting Features for Scale

This plan is essential for developers moving beyond basic coding into high-level system design. It bridges the gap between feature ideation and scalable execution, making it ideal for engineers preparing for senior roles or high-traffic environments.

2 h•4 섹션

학습 계획

Scale through Influence and Systems

This plan is essential for founders and leaders stuck in the daily grind who need to transition from operator to architect. It provides the roadmap to decouple personal time from revenue growth by leveraging systems and intellectual property.

1 h 30 m•3 섹션

학습 계획

Architecting Enterprise Asset Supply Chains

This learning plan is essential for solutions architects and engineering leaders tasked with scaling digital infrastructure. It bridges the gap between technical storage architecture and executive-level business value for modern media-heavy enterprises.

1 h 30 m•3 섹션

학습 계획

Scale business while optimizing life balance

This learning plan is designed for ambitious entrepreneurs and business leaders who feel trapped in day-to-day operations and want to break through growth plateaus. It's ideal for those who recognize that scaling their business requires not just working harder, but fundamentally transforming how they lead, delegate, and structure their companies while maintaining personal well-being.

4 h 8 m•4 섹션

학습 계획

The High-Impact Engineer's Growth System

This system is designed for ambitious software engineers looking to bridge the gap between technical proficiency and high-leverage impact. It provides a structured framework for mastering both the social dynamics of career growth and the deep cognitive skills required for architectural leadership.

1 h 45 m•4 섹션

학습 계획

Build, market, and scale online businesses.

This learning plan is essential for aspiring entrepreneurs and current business owners looking to transition from manual operations to a scalable digital enterprise. It provides a comprehensive roadmap for anyone wanting to master both the technical marketing skills and the leadership mindset required for long-term growth.

4 h 49 m•4 섹션

학습 계획

The Architecture of a Fearless Life

This plan is essential for professionals and seekers struggling with burnout, anxiety about the future, or the pressure of high-stakes results. It offers a blueprint for building resilience by integrating ancient wisdom into modern daily routines, making it ideal for anyone looking to find stability in an unpredictable world.

1 h 30 m•3 섹션

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

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

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

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

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

지금 바로 학습 여정을 시작하세요

11장

확장 가능한 시스템 설계기법

개요확장 가능한 시스템 설계기법 개요

한 권의 책, 다양한 듣기 방식.

When Scaling Becomes the Silent Killer of Your Business

The Existential Threat of Poor Availability

들리는 모든 단어를 눈으로 확인하세요

Flying Two Mistakes High: The Margin for Error

The Mathematics of Uptime: Understanding Availability Metrics

확장 가능한 시스템 설계기법에서 더 많은 것을 얻으세요

Reversing the Availability Death Spiral

Five Essential Focuses for Bulletproof Availability

들리는 모든 단어를 눈으로 확인하세요

Breaking the Monolith: The Service Revolution

Defining Service Boundaries: The Art of Decomposition

확장 가능한 시스템 설계기법에서 더 많은 것을 얻으세요

Managing Data in a Service Architecture

Graceful Degradation: The Art of Failing Well

들리는 모든 단어를 눈으로 확인하세요

The Cloud Revolution: Six Levels of Maturity

확장 가능한 시스템 설계기법 완독을 축하합니다

확장 가능한 시스템 설계기법의 핵심 주제

확장 가능한 시스템 설계기법의 명언

확장 가능한 시스템 설계기법의 등장인물

저자 소개

확장 가능한 시스템 설계기법 요약 다운로드

다른 사용자들도 좋아한 책

이 책에 대한 FAQ

What is Architecting for Scale by Lee Atchison about?

Who should read Architecting for Scale?

Is Architecting for Scale worth reading?

What is the STOSA model in Architecting for Scale?

이 학습 계획의 일부

High-load Rust

Data center development and policy

Hi load systems in rust

더 알아보기

1,000,000+ curious minds.

1,000,000+ curious minds.

한 권의 책, 다양한 듣기 방식.

When Scaling Becomes the Silent Killer of Your Business

The Existential Threat of Poor Availability

들리는 모든 단어를 눈으로 확인하세요

Flying Two Mistakes High: The Margin for Error

The Mathematics of Uptime: Understanding Availability Metrics

확장 가능한 시스템 설계기법에서 더 많은 것을 얻으세요

Reversing the Availability Death Spiral

Five Essential Focuses for Bulletproof Availability

들리는 모든 단어를 눈으로 확인하세요

Breaking the Monolith: The Service Revolution

Defining Service Boundaries: The Art of Decomposition

확장 가능한 시스템 설계기법에서 더 많은 것을 얻으세요

Managing Data in a Service Architecture

Graceful Degradation: The Art of Failing Well

들리는 모든 단어를 눈으로 확인하세요

The Cloud Revolution: Six Levels of Maturity

확장 가능한 시스템 설계기법 완독을 축하합니다

다른 사용자들도 좋아한 책

이 학습 계획의 일부

High-load Rust

Data center development and policy

Hi load systems in rust

더 알아보기

확장 가능한 시스템 설계기법 개요