비동기 방식은 동기 방식보다 더 많은 요청을 동시에 처리할 수 있기 때문에 서버의 성능이 크게 향상됩니다. 멀티스레딩이나 멀티프로세싱처럼 많은 메모리를 요구하지 않으며, 컨텍스트 스위칭으로 인한 오버헤드도 발생하지 않습니다. FastAPI는 async/await 구문으로 비동기 작업을 구현하며, 이는 벡엔드가 여러 I/O 바운드 작업(통신, 데이터베이스 쿼리, 외부 API 호출 등)을 동시에 논블록킹으로 처리할 수 있도록 하여, 대규모 트래픽을 효율적으로 처리할 수 있게 합니다.

선언형 프로그래밍은 주로 UI 상태와 상호작용에 집중하며, 이는 간단한 UI에 적합합니다. 그러나 현실의 프로젝트에서는 종종 복잡한 비즈니스 로직이 필요합니다. 선언형 방식은 이러한 비즈니스 로직을 다루기 어렵게 만들며, 명령형 프로그래밍의 직관적인 제어가 필요할 때가 많습니다.

Node.js는 싱글 스레드 이벤트 루프 모델을 채택하고 있습니다. 클라이언트의 접속이나 클라이언트로부터 요청을 받는 등의 모든 이벤트는 이벤트 루프에서 처리되며, 이벤트 루프는 메인 스레드에서만 동작합니다. 이벤트 루프에서 호출하는 이벤트 핸들러는 그것이 동작하는 동안 어떠한 이벤트도 신규로 생성하거나 처리하지 못합니다. ‘이벤트 생성 -> 이벤트 처리 -> 이벤트 처리 -> 이벤트 대기’와 같이 한번에 하나씩 순차적으로 실행됩니다.

XML과 JSON을 비교한 수많은 글은 이미 JSON이 XML보다 많은 강점을 갖고 있다고 말하고 있으며, 많은 개발자들 또한 이러한 내용에 공감하고 현재도 그리고 앞으로도 웹 API 입출력 형식으로 JSON을 선택할 것입니다.
우리는 지금까지 JSON의 비교 우위를 판단할 때 상대적으로 ‘더 적은 데이터의 양’과 상대적으로 ‘더 높은 처리 성능’ 등의 수치적 자료를 기준으로 하였습니다. 그러나 XML과 JSON을 비교하는 많은 글에서 간과하고 있지만 우리가 놓치고 있는 중요한 사실이 있습니다. 그것은 바로 데이터의 형식적 무결성 확보입니다.
노련한 개발자들은 이미 눈치채셨겟지만, 입력 데이터의 형식적 무결성 확보는 수치적인 약간의 성능 향상보다 더 중요하게 고려해야 하는 부분입니다. 즉, 웹 API의 입력 데이터와 출력 데이터의 무결성을 검증, 확보, 유지하는 과정은 산술적인 이익보다 시스템 동작에 더 중요할 수 있습니다.
1. 입출력 데이터의 무결성 확보를 위해 먼저 해야할 일은 커스텀 데이터 규약을 정의하는 문서를 작성하고 웹 API 개발자 및 이용자들과 공유하는 것입니다. 단, 이 규약 문서는 실제 프로그래밍 및 동작 단계에서 강제성이 있어야만 합니다. 강제성이 없는 문서는 그냥 메뉴얼 또는 가이드 수준일 뿐입니다.
2. 입력 데이터, 출력 데이터 또는 입출력 데이터 모두에 대하여 위 규약 문서를 통하여 일차적으로 자동 검증합니다. 이 과정은 규약 문서에 강제성을 제공하여 규약 문서가 실질적 영향력이 있게 만듭니다. 즉, 규약 문서는, 안따라도 상관없는 단순한 가이드 문서가 아니라 규약을 어기면 웹 API가 100% 에러를 유발하고 규약의 어느 부분을 어겼는지도 알려주는, 강력한 무결성 판단 도구가 됩니다.
3. 이렇게 입력, 출력, 또는 입출력 데이터에 대한 무결성이 확보되면 웹 API 개발자는 모든 문제를 웹 API의 실제 구현부로 가정할 수 있습니다. 즉, 웹 API가 오동작하였다면 그 원인 중에 적어도 ‘규약을 지키지 않은 입력 데이터가 웹 API 호출 시 인자로 입력’된 경우는 없게 됩니다. 또한 반대로 ‘출력 데이터의 무결성’ 까지 확보되면, 웹 API가 잘못된 형식의 데이터를 클라이언트에게 보내어 클라이언트가 파싱에 실패하는 경우도 사라집니다.
위와 같은 ‘무결성’ 부분에 있어 XML은 JSON과 비교할 수 없는 강점을 갖습니다. 특히 XML의 규약 문서로 사용되는 형식인 XSD(XML Schema Definition)는 오래된 역사에 걸맞게 잘 다듬어졌으며 정교하고 강력합니다. 웹 API 개발자 및 사용자는 웹 API의 XSD를 파일을 공유하고 확인하는 것 만으로 해당 웹 API의 호출 규약을 이해하고 문제없이 사용할 수 있습니다. 또한 웹 API 개발자는 동일한 XSD 파일을 통하여 임의의 XML 문서가 규약에 부합하는지 빠르고 편하게 자동 검증할 수 있습니다.

리플리카 서버는 기본적으로 읽기전용으로 운용됩니다. 이러한 특성을 활용하면 데이터베이스 서버의 부하를 줄이고, 데이터베이스를 억세스하는 어플리케이션의 동작 성능을 개선할 수 있습니다.
어플리케이션 개발 시, 데이터의 억세스 시간이 중요한 읽기쓰기 SQL 작업은 마스터 서버에 접속하여 수행하고, 데이터의 억세스 시간이 중요하지 않는 ‘읽기전용’ 작업은 리플리카 서버에 접속하여 수행하도록 합니다.
예를 들어, 서비스 어플리케이션은 항시 마스터 데이터베이스 서버에서 데이터를 조작하도록 하고, ‘많은 부하가 유발될 수 있는’ 관리자 사이트의 특정 내역 조회 기능에 대해서는 리플리카 데이터베이스 서버로부터 데이터를 가져오도록 하는 것입니다.
이렇게 하면, 큰 규모의 데이터에서 자료를 추출하게 될 때 발생하는 데이터베이스 서버 부하를 리플리카 서버가 대신 받아 처리하기에 마스터 서버가 받게 되는 부하가 크게 줄어듭니다.

다수의 고객에게 동시에 콘텐츠를 전달해야 하는 상용 웹 서비스의 경우 하나의 웹서버 만으로 운용될 수 없는 경우가 대다수입니다. 웹서버의 경우, 로드밸런서를 통해 트래픽을 동일한 여러 개의 웹서버로 분산하여, 각 웹서버가 받는 부하를 1/N로 줄일 수 있습니다.
그러나 정적인 콘텐츠가 아닌, 콘텐츠가 계속해서 추가되는 상황이라면 여러 개의 웹서버가 동일한 미디어 파일을 유지할 수 있도록 동기화 시켜야 하는 문제가 발생하게 됩니다. 그래서 다른 기능없이 오로지 미디어 콘텐츠 파일 만을 보관하고 제공하는 웹서버인 ‘미디어 콘텐츠 서버’를 별도로 만들어 이 서버가 높은 네트워크 대역폭을 지원하도록 하고, 서비스 기능을 수행하는 웹서버와 클라이언트 프로그램으로 부터의 접근이 이곳으로 일원화 되도록 합니다.
그러나 미디어 다운로드 트래픽이 계속 늘어난다면 어떻게 될까요? 단일 미디어 콘텐츠 전용 서버의 네트워크 대역폭을 무한대로 늘릴 수는 없습니다. 호스팅 업체의 최대 네트워크 대역폭에 도달하기도 전에 해당 서버의 네트워크 카드가 가진 대역폭 최대치에 먼저 도달하게 될 것입니다. 이럴 때는 어쩔 수 없이 미디어 콘텐츠 서버를 여러 대 운용해야 합니다. 미디어 콘텐츠 서버가 여러 대가 되면 역시 서버 간의 파일 동기화 문제가 발생합니다. 클라이언트가 어떤 임의의 내부 미디어 서버에 도달한다고 해도 같은 파일에 접근할 수 있어야 하는데 그것이 랜덤으로 (받을 수도 있고 못 받을 수도 있고) 된다면 안되니까요. 새로운 미디어 파일을 고객이 업로드하던 기업이 업로드하던 모든 미디어 콘텐츠 서버에는 동일한 시점에 동일하게 올라가야 합니다.