Books will be stored in unstructured low-cost object storage like S3. Metadata about books will be stored in a database. There will be a cache for the metadata. If searching directly on the database adds too much load, we can have a dedicated elasticsearch service for searching for books. There will be a web tier to serve the API. Behind that there will be a BookService that is responsible for loading books from S3 and streaming them over the websocket.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Database: Use a relational database since it is mostly read traffic, we may want to do JOINs for the different usecases, and the schema is mostly known and doesn't need extreme flexibility. It will have a books table that has columns for author id and publisher id, plus book metadata columns. It will have an authors table and a publishers table.
Cache: Requests to get a book metadata by ID will hit the cache first, which is Redis. If it misses, it retrieves the metadata from the database and stores it in the cache.
BookService: A stateless replicated microservice that receives gRPC requests from the web tier. On a request for streaming a book, it downloads the book from S3 to local disk and streams it to the client over websocket.