개발자가 알아야 할 SOLID를 잘 지키는 방법 (Java)

SOLID는 여전히 중요하다소프트웨어 설계의 다섯 가지 핵심 원칙인 SOLID는 명명된 지 20여 년이 지나가고 있지만, 여전히 개발자들에게 중요한 기준으로 자리잡고 있다. 최근 카카오뱅크의 안드로이드 개발자도 이를 언급하여, SOLID 원칙이 소프트웨어 설계에서 어떤 시사점을 제공하는지 강조한 바 있다.  모든 개발자가 알아야 할 SOLID의 진실 혹은 거짓기술 면접 자리에서 SOLID 5대 원칙에 대한 질문을 받아보신 분이라면 주목! 이 글에서는 SOLID 원칙의 역사와 장점, 그리고 각각의 원칙에서 중요한 점을 면접 상황 예시를 통해 가볍게 풀어보았습tech.kakaobank.com 다만 SOLID가 설계 품질을 높이기 위한 지침일 뿐, 모든 프로젝트에서 반드시 지켜야할 필수 요건이라거나 법이란 건..

• format_list_bulleted 설계
• · 2025. 1. 22.
• textsms

[인프라&아키텍처] 처리율 제한 장치 - 토큰 버킷 알고리즘

마이크로서비스 아키텍처라든지 분산 시스템을 설계하다보면 특정 서비스로의 요청 폭주를 방지하거나 공정한 자원 분배를 위해 얼만큼 트래픽을 관리할 것인지에 대한 처리율 제한 알고리즘도 설계해 반영할 일이 있다.쉽게 말해 "너무 많이 요청하지 말라"고 하기 위한 신호등 느낌이다. 한 번에 너무 많은 요청(클릭, 데이터 요청)이 들어온다면 시스템은 멈추거나 느려지는 현상이 나타날테니, 이를 위해 "몇 개까지만 허용할게" 라고 정해 그 이상은 거절한다든지, 멈추겠다든지 등을 결정해볼만 하다. 물론 과부화 요청에 대한 시스템의 처리속도의 향상과 더불어, 다수의 사용자 중 일부 사용자만 독점하지 않게하며 보안적으로도 안전성을 갖추기 위해 적용시킬 수 있다. 대표적인 처리율 제한 알고리즘 - 토큰 버킷 알고리즘을 알아..

• format_list_bulleted 설계
• · 2024. 12. 2.
• textsms

티스토리의 작심삼주이벤트를 백엔드 개발자가 고민한다면

요구사항 티스토리에서는 2024.11.07 - 11.27까지 21일 동안의 작심삼주 오블완 챌린지를 진행한다. 작심삼주 오블완 챌린지오늘 블로그 완료! 21일 동안 매일 블로그에 글 쓰고 글력을 키워보세요.www.tistory.com 가장 핵심적인 이벤트 진행 조건은 '매일 특정 태시태그를 단 연속된 21개의 포스팅 기록이 충족되는 것' 이다.더불어 이벤트 공지 내 하단의 확인 및 참여기준을 보면 여러 제한조건이 있는데, 이걸 백엔드 개발자가 보고 구현해야한다면 무엇을 고려해야했을까?  요구사항 추출 및 구현 상세화1. "한국 시간 기준"에 따른 시간 검증한국 시간 기준 00시부터 23시 59분요구사항에 따르면 모든 게시글의 작성 및 발행 시간이 한국 표준시(KST) 기준으로 계산되어야 한다. 따라서 서..

• format_list_bulleted 설계
• · 2024. 11. 27.
• textsms

채팅 서비스 설계 시 고려점-2 (서버 아키텍처 측면) [끝]

이전 포스팅 보기 이전에 채팅 시스템에 대해서 위와 같이 WebSocket 방식의 채팅 이면서 메시지는 NoSQL에 저장하는 형태를 고려해봤다.이제, 중간에 Server를 구체화할 예정이다. 무상태 서비스와 상태유지 서비스 구분짓기여러 서비스를 제공하는 서버에 대해서 상태에 따른 서비스를 분류할 필요가 있다.무상태서비스: 로그인, 회원가입, 배치, 공통유틸 등 전통적인 요청/응답 서비스 (클라이언트 상태 관리 X)상태유지서비스: 채팅서비스, 즉 클라이언트와 서버가 네트워크 연결을 유지해야 하는 서비스아래는 이러한 상태에 다른 서비스를 시각화했다.사용자의 요청에 따라 로드밸런서가 각 서버로 요청을 분산시키는 형태다.  이와 반대로, 상태 유지를 하는 채팅 서비스는 별도로 분리되어 로드밸런서의 영향을 받지 ..

• format_list_bulleted 설계
• · 2024. 9. 30.
• textsms

채팅 서비스 설계 시 고려점-1 (통신 아키텍처 측면)

채팅에도 여러 종류와 여러 요건이 따른다채팅 요구사항에 대한 체크리스트로 다음과 같은 것들이 있다.채팅의 규모1:1채팅인가(ex. 페이스북)? 그룹채팅인가(ex.디스코드)?그룹채팅이라면 인원의 제한이 따르는가?예상 트래픽, 처리 기준이 얼마나 되는가? (ft.DAU)플랫폼의 종류모바일앱인가 웹앱인가?하나의 계정이 여러 단말기로 접속할 수 있는가?채팅 메시지의 제한텍스트 이외의 파일, 링크 첨부 가능성이 있는가?메시지 개당 길이의 제한이 있는가?암호화의 필요성이 있는가?부가기능읽음 표시가 필요한가?접속 상태를 관리해야하는가? 요구사항을 정립했다면 이 요구사항을 충족시킬 시스템의 아키텍처를 그려보고 싶은데, 그 전에 사전적인 지식을 다시 상기시켜볼 필요가 있다.  채팅은  송신과 수신의 통신 시나리오가 다르..

• format_list_bulleted 설계
• · 2024. 8. 29.
• textsms