Design Decision Note

[metalalive]

Context & Use Cases

• This application supports saleable item updates, searches, product attribute labeling, and hierarchical tagging, with separation of concerns between public and internal-facing endpoints.
• this application is supposed to be read-intensive, that is, handles much more reads than writes.
• this application needs to process complex search query for saleable item fetch

Why Python?

• Rapid Prototyping & Readability: Python’s simplicity and concise syntax allow me to quickly develop and iterate on features. This speed is crucial when I’m still validating the features without expecting heavy load.
• Rich Ecosystem: mature frameworks (e.g., Blacksheep for web APIs, celery for RPC API, elasticsearch-py for data store repository) provide robust support for building and maintaining search applications.
• Alternative Considerations:
  • Raw performance is not highest priority for now, even if this application would face increasingly high load in the future, it is also feasible to move part of functions (that slows down application) into low-level Python C Extension or Rust (through PyO3) for performance gain (if necessary after profiling and in-depth analysis).

Search Technology Selection - Why ElasticSearch ?

• it is crucial that a data store can boost read speed, support complex search queries and full-text search.
• Indexing & Aggregation Capabilities: these features facilitate dynamic product filtering, faceting, and relevance ranking.
• Alternative Considerations:
  • PostgreSQL also supports full-text search, but complex query part might be lacking ; while ElasticSearch covers all of the requirement above, which aligns perfectly with the product search use case

Architecture & Separation of Concerns

• API Endpoints: Separate Web and RPC endpoints ensure that public-facing interactions are decoupled from internal application-to-application communications.
• Business Logic Isolation: Using a service layer with clearly defined responsibilities (e.g., saleable item update vs. search), which simplifies debugging and scaling each component independently.
• Data Flow & Repository Pattern: even though I'm currently using ElasticSearch as the datastore, the repository pattern abstracts data access so I can switch or upgrade the data layer with minimal impact on business logic.

Scalability & Future-Proofing

(TODO, complete this section)

• Current vs. Future Needs : acknowledge that while the current load doesn’t necessitate caching, the architecture leaves room for adding a caching layer (e.g., Redis) when needed.
• Highlight that using ElasticSearch and a microservice approach positions us well for future growth and more complex queries.