1.
채팅은 어떻게 구현할지에 대해 논의 해보셨나요!? api 명세를 보니 채팅 보내기 api만 있는데 해당 api를 통해 채팅 내용을 DB에 저장한다하면 상대방이 채팅내용을 받은 것을 어떻게 인지할 것인지? 에 대해 고민해보셔야 될 것 같습니다. ex) 웹소켓을 사용하거나 http polling 방식을 사용해 채팅상대방이 이를 인지할 수 있어야함
답변
2.
노션을 통해 유스케이스 등은 자세히 적혀있으나 해당 기능을 어떻게 구현할 것인지에 대해 자세하게 나와있는 곳이 아쉽습니다. 1번에서 채팅을 어떤식을 구현할지에 대해 여쭤본것과 동일한 맥락입니다
답변
3.
ERD 연관관계 설정은 좋아보입니다. 아쉬운점은 User 테이블에서 userId 대신 id만 적어도 유저의 아이디라는 것을 알 수 있습니다.
답변
4.
api 명세에서 복수형으로 써주신 것은 좋은데 계층형으로 적용되어있지 않아서 아쉽습니다. ex) 유저팔로워 목록확인 /v1/users/follower/{id} -> /v1/users/{userId}/followers 어떠한 유저에 대한 팔로워 목록 확인이기 때문에 뒤에 적는 것이 보편적인 restful api 원칙에 맞습니다.
답변
5.
로그인 방식은 세션방식을 쓸것인지 토큰방식을 쓸것인지 해당 값들을 어떠한 저장소에 저장할 것인지도 문서에 작성되어있으면 좋을 것 같습니다. 또한 면접때 매우 자주나오는 질문이기 때문에 세션,토큰 방식의 장단점과 왜 이기술을 선택했는지에 대해 정확한 논리가 있으면 좋을 것 같습니다.
답변
6.
모집글이 엄청 많아지게 된다면 (몇억개) 모집글 전체 조회 API를 통해 가져올 수 있을까요? 성능을 못버티지 않을까요? 이를 해결하려면 어떻게 해야할까요?
답변
7.
모집글 좋아요 api 명세도 /v1/posts/like 로 되어있는데 restful api에 맞게 설계된게 맞을까요? 어떤글에 대한 좋아요라면 다른 url을 사용하는게 맞을 것 같네요
답변
8.
어떤 모집글에 좋아요 개수가 몇천만개가 된다면 지금처럼 연관관계를 통해서 나타내면 성능에 문제가 생기지 않을까요? 이를 해결하려면 어떻게 해야할까요?
답변
9.
모집글 기술스택은 테이블이 꼭 분리되어야 할까요?
답변
10.
모집글 좋아요와 같이 다른테이블의 pk가 두 개가 있는 연관관계 테이블들은 조회할 때 쿼리가 어떻게 나갈까요?
답변
답변 참고
5번 질문
세션(Session) 방식:
장점:
1.
보안: 세션은 서버 측에서 유지되기 때문에 클라이언트에는 세션 식별자만 전달되고 실제 데이터는 서버에 저장되어 보안이 강화됩니다.
2.
쉬운 관리: 서버에서 세션을 관리하므로 클라이언트에 대한 유지 및 관리가 용이합니다.
3.
자동 로그아웃: 세션은 일정 기간 동안 유지되고 만료되면 자동으로 로그아웃이 될 수 있어 보안을 강화할 수 있습니다.
단점:
1.
확장성 이슈: 많은 사용자의 경우 서버 메모리에 대한 부담이 커질 수 있습니다.
2.
상태 유지: 세션은 상태를 유지하므로 RESTful 아키텍처와 어울리지 않을 수 있습니다.
3.
모바일 애플리케이션에서 제한: 모바일 애플리케이션의 경우 세션 유지가 서버 및 대역폭 부하를 일으킬 수 있습니다.
토큰(Token) 방식:
장점:
1.
확장성: 토큰은 서버에서 관리되지 않으므로 서버에 대한 부담이 적어질 수 있습니다.
2.
상태 없음(Stateless): 토큰 기반 인증은 상태를 서버에 저장하지 않으므로 서버의 확장성이 높아집니다.
3.
모바일 및 분산 애플리케이션에 적합: RESTful 아키텍처와 잘 어울리며, 모바일 및 분산 애플리케이션에서 사용하기 용이합니다.
단점:
1.
보안 관련 이슈: 토큰이 클라이언트에 저장되어 있기 때문에 안전한 저장 및 전송이 보장되어야 합니다.
2.
토큰 관리의 어려움: 토큰은 클라이언트에서 관리되므로 만료, 갱신, 재발급과 같은 관리가 필요합니다.
6번 질문
1.
페이징 (Paging):
•
결과를 페이지로 나누어 제공합니다. 클라이언트는 필요한 페이지만 요청하므로 전체 데이터를 가져오는 대신 일부만 로드됩니다.
•
예를 들어, offset과 limit 매개변수를 사용하여 페이지를 지정할 수 있습니다.
2.
인덱싱(Indexing):
•
데이터베이스에 적절한 인덱스를 설정하여 쿼리 성능을 향상시킵니다.
•
검색 조건에 맞는 인덱스를 사용하면 데이터를 빠르게 찾을 수 있습니다.
3.
캐싱(Caching):
•
자주 변경되지 않는 모집글 목록을 캐시하여 빠르게 반환할 수 있습니다.
•
캐시 전략을 고려하여 데이터의 일관성과 적절한 만료 전략을 설정합니다.
4.
부분 응답 (Partial Response):
•
클라이언트가 필요로 하는 속성만 응답으로 반환하도록 하는 기능을 제공합니다.
•
불필요한 데이터를 전송하지 않아 대역폭을 절약하고 응답 시간을 단축할 수 있습니다.
5.
검색 엔진 사용:
•
대용량 데이터에 대한 효율적인 검색을 지원하는 검색 엔진을 사용할 수 있습니다.
•
Elasticsearch, Solr 등의 검색 엔진을 통해 고급 검색 및 정렬 기능을 활용할 수 있습니다.
6.
비동기 처리:
•
대용량 데이터를 비동기적으로 처리하여 사용자에게 즉시 응답을 제공하고 백그라운드에서 데이터를 로드합니다.
•
클라이언트 측에서도 비동기 로딩 및 무한 스크롤과 같은 기술을 사용하여 부드러운 경험을 제공할 수 있습니다.
7.
요청 최적화:
•
클라이언트와 서버 간의 데이터 교환을 최적화합니다. 필요한 데이터만 요청하고, 필요 없는 데이터는 제외합니다.
•
필요한 경우 HTTP 압축을 사용하여 전송되는 데이터의 양을 최소화할 수 있습니다.
8.
분산 아키텍처 적용:
•
데이터베이스 및 서버 부하를 분산시켜 성능을 향상시킬 수 있는 분산 아키텍처를 고려합니다.
10번 질문
조회 쿼리:
1.
특정 사용자가 좋아요한 모든 모집글 조회:
sqlCopy code
SELECT Posts.*
FROM Posts
JOIN Likes ON Posts.PostID = Likes.PostID
WHERE Likes.UserID = [특정 사용자 ID];
SQL
복사
1.
특정 모집글에 좋아요를 누른 모든 사용자 조회:
sqlCopy code
SELECT Users.*
FROM Users
JOIN Likes ON Users.UserID = Likes.UserID
WHERE Likes.PostID = [특정 모집글 ID];
SQL
복사
이러한 쿼리는 JOIN을 사용하여 연결 테이블에 있는 두 테이블 간의 관계를 맺고, 필요한 조건을 추가하여 원하는 결과를 얻을 수 있습니다. 중요한 점은 JOIN 시에 사용되는 컬럼은 서로의 외래 키에 대응되어야 하며, 필요한 경우 추가적인 조건을 사용하여 데이터를 필터링할 수 있습니다.
