Component	Primary purpose	Use when	Watch out for
CDN	Cache content near users	Static assets, media, cacheable responses	Invalidation, stale content, private-data leakage
Load balancer	Distribute incoming traffic	Multiple service instances	Health checks, connection draining, sticky sessions
API gateway	Centralize API routing and policies	Multiple APIs or services	Becoming a bottleneck or policy monolith
Application service	Execute business logic	Domain operations and workflows	Stateful instances, overloaded responsibilities
Cache	Reduce repeated reads and latency	Hot or recomputable data	Staleness, eviction, stampedes
Relational database	Transactions and relational queries	Strong constraints and multi-row transactions	Hot rows, connection limits, write scaling
Document database	Flexible document-shaped records	Aggregate-oriented access patterns	Cross-document transactions and index design
Key-value store	Fast lookup by key	Sessions, counters, simple access patterns	Limited query flexibility
Search engine	Full-text and relevance search	Text search, filtering, ranking	Eventual indexing and operational complexity
Message broker	Decouple producers and consumers	Async jobs and event-driven workflows	Duplicate delivery, backlog, ordering
Object storage	Durable blob storage	Images, videos, backups, large files	Access control, metadata lookup, lifecycle policies
Stream processor	Process continuous event flows	Real-time metrics and transformations	Late events, replay, state management

A common request path: client → DNS/CDN → load balancer or gateway → application service → cache/database or message broker → response.

Not every architecture needs every component. Add a component only when a requirement, bottleneck, isolation boundary, or failure mode justifies it.