❓
물음표살인마 블로그
  • README
  • ALGORITHM
    • Sieve of Eratosthenes
    • Round Up
    • Binary Search
    • Union Find
    • Sorting Array
    • Lcm, Gcd
  • TechTalk Review
    • Template
  • Books
    • CS Note for Interview
      • Ch1. Design Pattern & Programming paradigm
        • 1.1.1 Singleton Pattern
        • 1.1.2 Factory Pattern
        • 1.1.4 Observer Pattern
        • 1.1.5 Proxty Pattern & Proxy Server
        • 1.1.8 Model-View-Controller Pattern
        • 1.2.1 Declarative and Functional Programming
        • 1.2.2 Object Oriented Programming
      • Ch2. Network
        • 2.2.1 TCP/IP Four-Layer Model
        • 2.2.1-1 TCP 3, 4 way handshake
        • 2.3 Network Devices L4, L7
        • 2.4.1 ARP, RARP
        • 2.4.2 Hop By Hop Communication
        • 2.4.3 IP Addressing Scheme
      • Ch3. Operating System
        • 3.1.1 Roles and Structure of Operating Systems
        • 3.2.1 Memory Hierarchy
        • 3.2.2 Memory Management
        • 3.3.1 Processes and Compilation Process
        • 3.3.3 Memory Structure of a Process
        • 3.3.4 Process Control Block (PCB)
        • 3.3.5 Multiprocessing
        • 3.3.6 Threads and Multithreading
        • 3.3.7 Shared Resources and Critical Sections
        • 3.3.8 Deadlock
        • 3.4 CPU Scheduling Algorithm
      • Ch4. Database
        • 4.1 Database Basic
        • 4.2 Normalization
        • 4.3 Transaction and Integrity
        • 4.4 Types of Databases
        • 4.5 Indexes
        • 4.6 Types of Joins
        • 4.7 Principles of Joins
      • Ch5. Data Structure
    • Learning the Basics of Large-Scale System Design through Virtual Interview Cases
      • 1. Scalability based on user counts(1/2)
      • 1. Scalability based on user counts(2/2)
      • 2.Back-of-the-envelope estimation
      • 3. Strategies for System Design Interviews
      • 4. Rate Limiter
      • 5. Consistent Hashing
      • 6. Key-Value System Design
      • 7. Designing a Unique ID Generator for Distributed Systems
      • 8. Designing a URL Shortener
      • 9. Designing a Web Crawler
      • 10. Notification System Design
      • 11. Designing a News Feed System
      • 12. Chat System Design
      • 13. AutoComplete
      • 14. Design YouTube
      • 15. Design Google Drive
      • Loadbalancer Algorithms
      • Cache tier
      • CDN, Content Delivery Network
      • Stateless Web tier
    • Computer System A programmer's perspective
    • Effective Java
      • Item 1. Consider Static Factory Methods Instead of Constructors
      • Item 2. Consider a Builder When Faced with Many Constructor Parameters
      • Item 3. Ensure Singleton with Private Constructor or Enum Type
      • Item 4. Enforce Noninstantiability with a Private Constructor
      • Item 5. Prefer Dependency Injection to Hardwiring Resources
      • Item 6. Avoid Creating Unnecessary Objects
      • Item 7. Eliminate Obsolete Object References
      • Item 8. Avoid Finalizers and Cleaners
      • Item 9.Prefer try-with-resources to try-finally
      • Item10. Adhering to General Rules When Overriding equals
        • Handling Transitivity Issues
        • Ensuring Consistency
      • Item11. Override hashCode When You Override equals
      • Item12. Always Override toString
        • Always Override toString
      • Item13. Override Clone Judiciously
      • Item14. Consider Implementing Comparable
      • Item15. Minimize the Accessibility of Classes and Members
      • Item16. Accessor Methods Over Public Fields
      • Item17. Minimize Mutability
      • Item18. Composition over inherentance
      • Item19. Design and Document for Inheritance, or Else Prohibit It
      • Item20. Prefer Interfaces to Abstract Classes
      • Item21. Design Interfaces with Implementations in Mind
      • Item22. Use Interfaces Only to define Types
      • Item23. Prefer Class Hierarchies to Tagged Classes
      • Item24. Favor Static Member Classes Over Non-Static
      • Item28. Use Lists Instead of Arrays
      • Item29. Prefer Generic Types
      • Item30. Favor Generic Methods
    • Head First Design Patterns
      • Ch1. Strategy Pattern
      • Ch2. Observer Pattern
        • Ver1. Ch2. Observer Pattern
      • Ch3. Decorator Pattern
        • Ch3. Decorator Pattern
      • Ch4. Factory Pattern
      • Ch5. Singleton Pattern
      • Ch6. Command Pattern
      • Ch7. Adapter and Facade Pattern
      • Ch8. Template Method Pattern
    • Digging Deep into JVM
      • Chapter 2. Java Memory Area & Memory Overflow
      • Chapter 3. Garbage Collector & Memory Allocation Strategy (1/2)
      • Chapter 3. Garbage Collector & Memory Allocation Strategy (2/2)
      • Chapter 5. Optimization Practice
      • Chapter 6. Class file structure
      • Chapter 8. Bytecode Executor Engine (1/2)
  • Interview Practices
    • Restful API Practices
      • Url Shortener API
      • Event Ticket Reservation API
      • Course Management API
      • Search posts by tags API
      • Online Code platform API
      • Simple Task Management API
      • Event Participation API
      • Review System API
      • Car management API
      • Online Library
    • Tech Review
      • if(kakao)
        • Kakao Account Cache Migration / if(kakao)2022
        • Improving the Anomaly Detection System for KakaoTalk Messaging Metrics / if(kakao) 2022
        • Standardizing API Case Handling Without Redeployment / if(kakaoAI)2024
        • JVM warm up / if(kakao)2022
    • Naver Computer Science
      • Process & Thread
      • TCP & UDP
      • Spring & Servlet
      • Filter & Interceptor & AOP
      • Equals() & ==
      • Dependency Injection
      • Object Oriented Programming
  • F-Lab
    • Week1
      • Client & Server
      • HTTP
      • TCP/UDP
      • REST API
      • Questions
        • Object Oriented Programming
        • HTTP
        • Process & Thread
        • Data Structure
    • Week2
      • OSI 7 layer
      • Web vs WAS
    • Week3
      • RDB vs NoSQL
      • RDB Index
      • Cache
      • Redis
      • Messaging Queue
    • Week4
      • Project - Ecommerce
    • Week5
      • ERD - 1
    • Week6
      • Ecommerce - 2
      • Role
      • pw hashing && Salt
      • CreatedAt, ModifiedAt
      • JWT
      • Copy of ERD - 1
    • Week7
      • Vault (HashiCorp Vault)
    • Week 8
      • Api Endpoints
    • Week10
      • Product Create Workflow
  • TOY Project
    • CodeMentor
      • Implementation of Kafka
      • Project Improvement (Architectural Enhancements)
      • Communication between servers in msa
  • JAVA
    • MESI protocol in CAS
    • CAS (Compare and Set)
    • BlockingQueue
    • Producer & Consumer
    • Synchronized && ReentrantLock
    • Memory Visibility
    • Checked vs Unchecked Exception
    • Thread
    • Batch delete instead of Cascade
    • Java Questions
      • Week 1(1/2) - Basic Java
      • Week 1(2/2) - OOP
      • Week 2(1/2) - String, Exception, Generic
      • Week2(2/2) Lambda, Stream, Annotation, Reflection
      • Week3(1/2) Collections
      • Week3(2/2) Threads
      • Week4 Java Concurrency Programming
      • Week5 JVM & GC
    • Java 101
      • JVM Structure
      • Java Compiles and Execution Method
      • Override, Overload
      • Interface vs Abstract Class
      • Primitive vs Object Type
      • Identity and equality
      • String, StringBuilder, StringBuffer
      • Checked Exceptions and Unchecked Exceptions
      • Java 8 methods
      • Try-with-reources
      • Strong Coupling and Loose Coupling
      • Serialization and Deserialization
      • Concurrency Programming in Java
      • Mutable vs Immutable
      • JDK vs JRE
  • SPRING
    • DIP. Dependency Inversion Principal
    • Ioc container, di practice
    • @Transactional
    • Proxy Pattern
    • Strategy Pattern
    • Template Method Pattern
    • using profile name as variable
    • Spring Questions
      • Spring Framework
      • Spring MVC & Web Request
      • AOP (Aspect-Oriented Programming)
      • Spring Boot
      • ORM & Data Access
      • Security
      • ETC
  • DATABASE
    • Enhancing Query Performance & Stability - User list
    • Ensuring Data Consistency, Atomicity and UX Optimization (feat.Firebase)
    • Redis: Remote Dictionary Server
    • Database Questions
      • Week1 DBMS, RDBMS basics
      • Week2 SQL
      • Week3 Index
      • Week4 Anomaly, Functional Dependency, Normalization
      • Week5 DB Transaction, Recovery
    • Normalization
      • 1st Normal Form
      • 2nd Normal Form
      • 3rd Normal Form
  • NETWORK
    • HTTP & TCP head of line blocking
    • HTTP 0.9-3.0
    • Blocking, NonBlocking and Sync, Async
    • Network Questions
      • Week1 Computer Network Basic
      • Week2(1/3) Application Layer Protocol - HTTP
      • Week2(2/3) Application Layer Protocol - HTTPS
      • Week2(3/3) Application Layer Protocol - DNS
      • Week3 Application Layer
      • Week4 Transport Layer - UDP, TCP
      • Week5 Network Layer - IP Protocol
    • Network 101
      • https://www.google.com
      • TCP vs UDP
      • Http vs Https
      • TLS Handshake 1.2
      • HTTP Method
      • CORS & SOP
      • Web Server Software
  • OS
    • Operating System Questions
      • Week1 OS & How Computer Systems Work
      • Week2(1/2) Process
      • Week2(2/2) Thread
      • Week3 CPU Scheduling
      • Week4 Process Synchronize
      • Week5 Virtual Memory
    • Operating System 101
      • Operating system
        • The role of the operating system
        • The composition of the operating system.
      • Process
        • In Linux, are all processes except the initial process child processes?
        • Zombie process, orphan process
        • (Linux) Daemon process
        • Process address space
        • Where are uninitialized variables stored?
        • Determination of the size of the Stack and Heap
        • Access speed of Stack vs Heap
        • Reason for memory space partitioning
        • Process of compiling a process
        • sudo kill -9 $CURRENT_PID
      • Thread
        • Composition of a thread's address space
      • Process vs Thread
        • Creation of processes and threads in Linux
      • Multiprocessing
        • Web Browser
        • Implementation of multiprocessing
        • Application areas of multiprocessing
      • Multithreading
        • Application areas of multithreading
      • Interrupt
        • HW / SW Interrupt
        • Method of handling interrupts
        • Occurrence of two or more interrupts simultaneously
      • Polling
      • Dual Mode
        • Reason for distinguishing between user mode and kernel mode
      • System call
        • Differentiation between system calls
        • Types of system calls
        • Execution process of a system call
      • Process Control Block (PCB)
        • PCB의 구조
        • 쓰레드는 PCB를 갖고 있을까?
        • 프로세스 메모리 구조
      • Context switching
        • Timing of context switching
        • Registers saved during context switching
        • Context switching in processes
        • Context switching in threads
        • Difference between context switching in processes and threads
        • Information of the current process during context switching
      • Interprocess Communication (IPC)
        • Cases where IPC is used
        • Process address space in IPC Shared Memory technique
        • Types of IPC
  • COMPUTER SCIENCE
    • Computer Architecture 101
      • 3 components of a computer
      • RAM vs ROM
      • CPU vs GPU
      • SIMD
      • Two's complement
      • Harvard Architecture vs. von Neumann Architecture
      • The structure of a CPU.
      • Instruction cycle (CPU operation method)
      • Instruction pipelining
      • Bus
      • Memory area
      • Memory hierarchy structure
        • Reason for using memory hierarchy structure
      • Cache memory
      • L1, L2, L3 Cache
      • Locality of reference (cache)
      • Fixed-point vs Floating-point
        • epresentation of infinity and NaN (Not a Number) in floating-point
      • RISC vs CISC
      • Hamming code
      • Compiler
      • Linking
      • Compiler vs Interpreter
      • Mutex vs Semaphore
      • 32bit CPU and 64bit CPU
      • Local vs Static Variable
      • Page
  • Programming Paradigm
    • Declarative vs Imperative
  • JPA, QueryDsl
    • why fetchResults() is deprecated
  • PYTHON
    • Icecream
  • FASTAPI
    • Template Page
  • LINUX
    • Template Page
  • DATA STRUCTURE
    • Counting Sort
    • Array vs Linked List
  • GIT, Github
    • git clone, invalid path error
  • INFRA
    • Template Page
  • AWS
    • Server Log Archive Pipeline
    • Image Processing using Lambda
  • DOCKER
    • Docker and VM
    • Python Executable Environment
    • Docker commands
  • docker-compose
    • Kafka, Multi Broker
  • KUBERNATES
    • !Encountered Errors
      • my-sql restarts
      • kafka producer: disconnected
    • Kubernetes Components
    • Helm
      • Helm commands
    • Pod network
    • Service network
      • deployment.yaml
      • services.yaml
    • Service type
      • Cluster IP
      • NodePort
    • service-name-headless?
    • kube-proxy
  • GraphQL
    • Template Page
  • WEB
    • Template Page
  • Reviews
    • Graphic Intern Review
    • Kakao Brain Pathfinder Review
    • JSCODE 자바 1기 Review
  • 😁Dev Jokes
    • Image
      • Plot twist
      • Priorities
      • SQL join guide
      • Google is generous
      • Genie dislikes cloud
      • buggy bugs
      • last day of unpaid internship
      • what if clients know how to inspect
      • its just game
      • how i wrote my achievement on resume
      • self explanatory
      • chr(sum(range(ord(min(str(not))))))
Powered by GitBook
On this page
  • 1. 문제 정의
  • 2. 고수준 설계
  • 3. 세부 설계
  • 3.1 이벤트 생성 및 큐잉
  • 3.2 알림 생성기
  • 3.3 알림 전송기
  • 4. 확장성과 가용성
  • 5. 사용자 맞춤형 알림
  • 6. 장애 처리
  • 7. 확장성 및 성능 최적화
  • 7.1 이벤트 처리 최적화
  • 7.2 데이터베이스 최적화
  • 7.3 시스템 모니터링 및 자동 확장
  • 8. 알림 시스템의 사례 연구
  • 9. 장애 대응 및 복구 계획
  • 9.1 장애 시나리오 분석
  • 9.2 데이터 복구 및 롤백
  1. Books
  2. Learning the Basics of Large-Scale System Design through Virtual Interview Cases

10. Notification System Design

알림 시스템 설계

알림 시스템은 다양한 사용자가 필요로 하는 정보나 이벤트를 실시간으로 전달하기 위해 설계된 중요한 시스템입니다. 오늘날 대규모 애플리케이션은 사용자가 필요한 정보에 빠르게 접근할 수 있도록 하는 알림 시스템을 갖추고 있으며, 이는 사용자의 경험을 향상시키는 중요한 요소로 자리잡고 있습니다.

1. 문제 정의

알림 시스템의 주요 목적은 사용자가 시스템에서 발생하는 중요한 이벤트에 대해 빠르게 인지할 수 있도록 알림을 전달하는 것입니다. 이를 위해 시스템은 다음과 같은 기능을 제공해야 합니다.

  • 다양한 채널 지원: 이메일, SMS, 푸시 알림 등 다양한 방법으로 알림을 보낼 수 있어야 합니다.

  • 높은 확장성: 수백만 명의 사용자에게 동시에 알림을 보낼 수 있어야 합니다.

  • 낮은 지연 시간: 이벤트 발생 후 가능한 빨리 알림을 전달해야 합니다.

  • 사용자 설정 지원: 각 사용자가 자신의 알림 수신 방법을 설정할 수 있어야 합니다.

2. 고수준 설계

알림 시스템의 고수준 아키텍처는 다음과 같은 구성 요소로 나눌 수 있습니다.

  1. 이벤트 생성기: 시스템에서 발생하는 이벤트를 감지하여 알림 시스템에 전달하는 역할을 합니다.

  2. 이벤트 큐: 이벤트 생성기로부터 수신된 이벤트를 큐에 저장하여 알림 서비스로 전달합니다.

  3. 알림 생성기: 이벤트를 처리하여 알림을 생성합니다. 사용자의 알림 설정에 따라 알림의 형태와 채널을 결정합니다.

  4. 알림 전송기: 생성된 알림을 사용자가 설정한 채널로 전송합니다.

  5. 알림 로그: 전송된 알림의 기록을 보관하여 추적 및 분석을 가능하게 합니다.

3. 세부 설계

3.1 이벤트 생성 및 큐잉

이벤트 생성기는 시스템 내의 다양한 서비스에서 발생하는 이벤트를 수집합니다. 이 이벤트는 특정 사용자의 동작일 수도 있고, 시스템에서 감지한 이상 상황일 수도 있습니다. 이벤트는 일단 생성된 후 이벤트 큐에 저장됩니다.

이벤트 큐는 메시지 큐 또는 스트림 처리 플랫폼으로 구현할 수 있으며, 여기서 중요한 것은 이벤트의 순서 보장과 확장성입니다. 일반적으로 Apache Kafka, RabbitMQ 같은 메시지 브로커를 사용하여 이러한 요구 사항을 충족시킬 수 있습니다.

3.2 알림 생성기

알림 생성기는 이벤트 큐로부터 이벤트를 수신하여 알림을 생성합니다. 이 단계에서는 다음과 같은 작업이 이루어집니다.

  • 이벤트 처리: 이벤트의 유형에 따라 알림 메시지를 생성합니다.

  • 사용자 설정 확인: 사용자별 알림 설정을 조회하여 어떤 채널로 알림을 보낼지 결정합니다.

  • 알림 스케줄링: 필요에 따라 알림을 즉시 보내지 않고, 예약된 시간에 발송할 수 있도록 합니다.

이 과정에서는 사용자가 알림을 어떻게 받기를 원하는지에 대한 정보를 기반으로 맞춤형 알림이 생성됩니다.

3.3 알림 전송기

알림 전송기는 알림 생성기에서 생성된 알림을 실제 사용자에게 전달하는 역할을 합니다. 이 때 여러 가지 채널을 통해 알림을 전송할 수 있으며, 각 채널은 다음과 같은 방식으로 구현됩니다.

  • 이메일: SMTP 서버를 통해 이메일을 발송합니다.

  • SMS: SMS 게이트웨이를 통해 메시지를 발송합니다.

  • 푸시 알림: 모바일 기기나 웹 브라우저로 푸시 알림을 전송합니다.

각 채널은 독립적으로 운영되며, 전송 실패 시 재시도 메커니즘을 가지고 있어야 합니다. 예를 들어, 이메일 전송 실패 시 다른 이메일 서버를 이용해 재전송할 수 있는 기능이 필요합니다.

4. 확장성과 가용성

대규모 알림 시스템은 수많은 이벤트와 사용자 요청을 처리해야 하기 때문에 높은 확장성이 필요합니다. 이를 위해 다음과 같은 방식을 적용할 수 있습니다.

  • 수평적 확장: 알림 생성기와 전송기를 여러 대의 서버에 분산시켜 운영하여 처리량을 늘립니다.

  • 파티셔닝: 이벤트와 알림 데이터를 파티셔닝하여 여러 노드에서 병렬로 처리할 수 있도록 합니다.

  • 지연 처리: 비동기 처리를 통해 이벤트와 알림의 병목 현상을 줄이고 시스템의 응답성을 유지합니다.

또한, 가용성을 높이기 위해 이벤트 큐와 데이터베이스의 복제 및 장애 복구 전략을 설계해야 합니다. 장애 발생 시에도 시스템이 안정적으로 작동하고, 알림이 유실되지 않도록 설계해야 합니다.

5. 사용자 맞춤형 알림

알림 시스템은 사용자의 요구와 선호도에 따라 맞춤형으로 동작해야 합니다. 이를 위해 다음과 같은 기능이 필요합니다.

  • 사용자 프로필 관리: 각 사용자의 알림 선호도를 저장하고 관리합니다.

  • 알림 필터링: 사용자가 관심 있는 알림만 수신할 수 있도록 필터링 기능을 제공합니다.

  • 다중 채널 지원: 사용자가 원하는 채널로만 알림을 받을 수 있도록 채널 선택 기능을 제공합니다.

예를 들어, 사용자가 이메일과 푸시 알림 중 푸시 알림만 받기를 원한다면, 시스템은 이 설정에 따라 푸시 알림만 발송하도록 해야 합니다.

6. 장애 처리

알림 시스템은 고가용성을 요구하며, 이를 위해 장애 처리 메커니즘이 필수적입니다. 장애가 발생했을 때는 다음과 같은 전략을 사용할 수 있습니다.

  • 재시도 로직: 알림 전송에 실패했을 때 일정 횟수만큼 재시도를 수행합니다.

  • 장애 감지: 알림 전송 과정에서 문제가 발생했는지 모니터링하고, 자동으로 관리자에게 보고하는 시스템을 구축합니다.

  • 데이터 복구: 장애로 인해 손실된 알림 데이터를 복구할 수 있는 기능을 설계합니다.

장애가 발생하더라도 사용자는 시스템의 안정성을 느낄 수 있어야 하며, 알림이 적시에 전달되는 것을 보장해야 합니다.

7. 확장성 및 성능 최적화

알림 시스템이 대규모 트래픽을 처리하기 위해서는 고성능을 유지하면서 확장성을 확보하는 것이 중요합니다. 이를 위해 다음과 같은 전략을 사용할 수 있습니다.

7.1 이벤트 처리 최적화

  • 비동기 처리: 이벤트를 비동기로 처리하여 시스템의 응답성을 높입니다. 이벤트 생성과 알림 전송을 독립적으로 처리함으로써 병목 현상을 줄일 수 있습니다.

  • 배치 처리: 일정량의 이벤트가 쌓이면 이를 배치로 처리하여 시스템 자원을 효율적으로 사용합니다. 예를 들어, 대량의 이메일을 한 번에 전송하기 위해 배치 작업을 활용할 수 있습니다.

7.2 데이터베이스 최적화

  • 인덱싱: 알림 관련 데이터를 저장하는 데이터베이스에 적절한 인덱스를 추가하여 조회 속도를 높입니다. 특히, 사용자별 알림 설정이나 로그 데이터를 자주 조회하는 경우, 인덱스 최적화가 필요합니다.

  • 캐싱: 자주 접근하는 사용자 설정 정보나 알림 내용을 캐시에 저장하여 데이터베이스 접근 횟수를 줄입니다. Redis와 같은 메모리 기반 캐시 시스템을 활용할 수 있습니다.

7.3 시스템 모니터링 및 자동 확장

  • 모니터링 도구: 시스템의 상태를 실시간으로 모니터링하여 문제가 발생할 가능성을 조기에 탐지합니다. Prometheus, Grafana와 같은 도구를 사용하여 알림 처리량, 지연 시간, 오류율 등을 추적할 수 있습니다.

  • 자동 확장: 클라우드 인프라를 사용하여 트래픽 증가에 따라 서버를 자동으로 확장합니다. 예를 들어, AWS의 오토스케일링 기능을 사용하여 필요 시 서버 인스턴스를 자동으로 추가할 수 있습니다.

8. 알림 시스템의 사례 연구

8.1 대규모 전자상거래 플랫폼

대규모 전자상거래 플랫폼에서 알림 시스템은 중요한 역할을 합니다. 사용자가 상품을 구매하거나, 배송 상태가 변경될 때마다 실시간으로 알림을 받을 수 있어야 합니다.

  • 이벤트 발생: 사용자가 결제를 완료하거나 상품이 배송 준비 상태로 전환될 때 이벤트가 발생합니다.

  • 알림 생성 및 전송: 이벤트 발생 후, 알림 생성기는 해당 이벤트를 분석하여 사용자가 설정한 채널로 알림을 전송합니다. 예를 들어, 결제 완료 알림은 이메일로, 배송 상태 변경 알림은 푸시 알림으로 전송됩니다.

  • 확장성 관리: 할인 이벤트 기간 동안 트래픽이 급증하는 경우를 대비해 시스템이 자동으로 확장될 수 있도록 설계합니다. 이를 통해 수십만 명의 사용자에게 동시에 알림을 보낼 수 있습니다.

8.2 소셜 미디어 플랫폼

소셜 미디어 플랫폼에서는 사용자가 친구의 새로운 게시물, 댓글, 메시지 등을 빠르게 인지할 수 있도록 알림 시스템을 활용합니다.

  • 이벤트 발생: 사용자가 새로운 게시물을 작성하거나 댓글을 달 때 이벤트가 발생합니다.

  • 사용자 맞춤 알림: 사용자의 알림 설정에 따라 특정 친구의 게시물에 대해서만 알림을 받거나, 모든 활동에 대해 알림을 받도록 설정할 수 있습니다.

  • 실시간 처리: 소셜 미디어의 특성상 실시간성이 매우 중요합니다. 사용자가 앱을 열지 않아도 푸시 알림을 통해 실시간으로 중요한 소식을 전달받을 수 있어야 합니다.

9. 장애 대응 및 복구 계획

알림 시스템이 중단 없이 동작하도록 하기 위해서는 장애 발생 시에도 신속하게 대응할 수 있는 복구 계획을 마련해야 합니다.

9.1 장애 시나리오 분석

  • 알림 전송 실패: 네트워크 문제나 전송 채널의 장애로 인해 알림 전송이 실패할 수 있습니다. 이 경우, 시스템은 자동으로 재시도를 시도하거나, 다른 채널을 통해 대체 전송을 시도합니다.

  • 시스템 과부하: 갑작스러운 트래픽 증가로 인해 시스템이 과부하 상태가 될 수 있습니다. 이를 해결하기 위해 오토스케일링과 같은 자동 확장 기능을 활용합니다.

9.2 데이터 복구 및 롤백

  • 이벤트 재처리: 장애로 인해 처리되지 않은 이벤트는 큐에 저장된 상태로 남아있으며, 시스템이 정상화되면 자동으로 재처리됩니다.

  • 데이터 백업 및 복원: 알림 로그와 사용자 설정 데이터는 주기적으로 백업되어야 하며, 장애 발생 시 이를 복원할 수 있는 절차가 마련되어야 합니다.

Previous9. Designing a Web CrawlerNext11. Designing a News Feed System

Last updated 9 months ago