개인 프로젝트가 아닌 상용화 되는 서비스는 다 synchronized로 되어있는 자료구조를 쓰나요?

갑자기 너무 궁금해졌는데요

몇몇 기술블로그 내용을 첨언하면,

대표적으로 StringBuilder와 StringBuffer 중 StringBuffer를 사용하는 것을 권장하는 이유는, 실 운용되는 서비스는 단일 쓰레드 환경이 아니기 때문이다

라고 하는데

위 인용을 그대로 서비스에 적용시키면, 실제 고객 대상으로 운영되는 서비스들은 1명의 고객만 있는 것이 아니니까, 해당 서비스를 구현하는 모든 로직은 다 Thread-safe하게 구현해야 하므로 synchronized 처리된 자료구조(이를테면 Stack) 같은 것만 써야 하는 거 같은데...

이게 맞나요?

개인적인 생각으로는 자유게시판 같은 조회수의 경우 레이스 컨디션 문제가 발생해도 크게 상관이 없다고 생각이 들어서 그냥Thread-unsafe한 자료구조를 쓰고, 성능을 챙기는 게 낫지 않을까? 생각이 들거든요

그리고 레이스 컨디션이 발생되면 안 되는 기능의 경우 해당 로직 부분만 Thread-safe하게 구현하면 되지 않을까 싶긴 합니다

마지막으로 또 궁금한 점은, Thread-safe한 로직을 구현할 때

synchronized로 구현된 자료구조를 쓰는 게 좋은지, 혹은 내가 필요한 부분만 synchronized키워드를 통해 핸들링하는 게 좋을지 (만약 쓰레드가 너무 많이 몰린다 싶으면 세마포어 같은 것을 적용시키구요)

또는 락을 통해 애초에 쓰레드 하나만 접근하게 하고, Thread-unsafe하게 구현하여 레이스 컨디션도 발생하지 않고 성능을 챙기는 게 좋은지

뭐 개발에는 정답이 없다곤 하지만

각각 장단점이 존재할 텐데,, 관련해서 찾아보고 있긴 하지만 명쾌한 해답이 나오질 않아서 질문드립니다.

보통 실운용되는 서비스는 어떤 방법을 지향하나요?