TDz

Вопрос очень обобщенный, уточните пожалуйста масштаб проекта, т.к. раздутость архитектуры зависит напрямую от количества фишек и ожидаемой нагрузки, от списка юзкейсов в первую очередь. Я разрабатывал ряд крупных книжных проектов архитектура в целом где-то такая

1) ядро, хранит базовые сущности (книги, авторов, коллекции, категории, серии, издания, итд) и их связи. Предоставляет такие сервисы как GetBookById, GetListByCategory, GetListByAuthor, GetListByCollection... если проект большой и распределенный к к ядру идут несколько "декораторов" - они подбирают и сериализуют полученные данные в требуемое представление (JSON/XML для предоставления API, объекты разной степени детализованности для внутреннего использования)

Крутится как правило на стандартных базах, т.к. набор фич ядра довольно примитивен а паттерны доступа простые. Ну а кодит кто на чём горазд. Каждой сущности таблица, связи как правило n-m так что сразу заводите единый реестр XtoY (ну или для каждой пары свой если хотите).

2) индексатор берёт данные из ядра и генерирует на их основании метаданные (графы, полнотекстовые индексы, prediction индексы, стоплисты итд). Поиск по этим метаданным значительно более эффективный чем выборки их базы на сложных и запросах. Также индексатор позволяет осуществлять быстрый полнотекстовый поиск по описаниям данным и даже внутренностям книг и делать выборки типа "дай мне книги на немецком, изданные между 1920 и 1940 на исторические темы авторами чьё имя начинается на А и которые имеют рейтинг не менее 4 а стоят не более 20 баксов, нго только те у которых в описании есть слово любовь а в тайтле либо ненависть либо смерть".

тут использ-уют как правило спец демоны типа sphinx/lucene

3) Фасеточный поисковик собтвенно умеет убращаться к индексаторам и из полученных в прошлом модуле метаданных получать полезные функции типа "какие книги похожи на эту", "какие авторы в разделе наиболее популярны", накладывать фильтры на листинги сущностей итд

4) Фронт-энд - собственно логика отображения сайта, код состоит по большей части из запросов к ядру и фасеточнику и шаблонизатора который их ответ завернёт в красивый лейаут

5) CDN - хранилище и система доставки статических файлов. Обложки книг, семплы, сами книги итд. Ресайзилка картинок, управление кешем, защита от скачивания итд итп. На высоконагруженном проекте тут логики может быть довольно много. На маленьком сайте достаточно тупо складывать файлики в папочку ))))

6) Редакционная система - книги товар с огромным количеством важных метаданных, критичных для юзера (если книги научные), иногда нужна серьёзная система сбора и модификации этих метаданных

В общем говорить можно долго, если решите всерьёз заняться - пишите. Поделюсь опытом и наработками

Я играюсь с Magento, он весьма силён, но больше 100к наименований товара начинает тупить

1. Т.н. оффлайн браузер — качалка сайта. Выкачивает неспеша сайт, упаковывает в зип, отдаёт вопрошающему
2. Файлдаунлоадер — все хотят качать из инета по всяким неудобным технологиям (файлообменники/торренты/п2п) и получать по удобным (ftp/http/webdav/etc)
3. Прокси для пауков. Паукам чужим надо много айпи, много канала, трафик исключительно входящий, жлементрано контролируется. Единственное в лизвебе врядли у вас много IP
4. Разнообразные задачи на всасывание и фильтрацию. У меня например сейчас есть задача качать терабайтами и отсеивать 99% дуьблирующихся материалов

Единственный свособ удостовериться что клиент получил весь файл это проверить получил ли он все данные и проверить не случилось ли ошибки. Для хардкор случая будем думать что клиент качает файл кусками в много потоков и каждый кусок считается отдельной завершенной отдачей. Тогда единственный способ удостовериться что файл отдан это просуммировать размеры и сопоставить ренжи. А значит либо вы пишете лог подробный включающий эти вещи, либо используете post_action с сооответсвующими переменными

Проверить отсутствие ошибок можно только парся лог. Для удосбтва парсинга надо настроить под себя формат и левел лога и парсить его сопоставляя залогированные запросы. К сожалению это всё равно не даёт гарантии что клиент файл получил ибо отсутствие HTTP ошибок не гарантирует корректного сохранения на винте.

Если вам надо хардкорно удостовериться что файл упал на винт клиента в целости и сохранности — делайте даунлоадер на флеше, ява, сильверлайте или другой клиентсайд технологии, которая сможет проверить результат скачки. Оно вам точно надо?

Специально для всяких каунтеров была директива post_action которая позволяет указать что будет запускаться после завершения запроса. Там можно подключить встроенный перл, мемкеш, фастцги, что угодно для умного подсчёта. Но если запрашивають часто то вешайте специальный лог на картинки в удобном для парсинга формате и его и парсите раз в X минут. Это с точки зрения нагрузки идеальный вариант. Также есть вариант со встроенными переменными, но больно он муторный