Database and Data Services Design: RDS, DCS, DWS, DDM and the Data Lake
What to know
Classify the workload first: transactional (OLTP), caching, analytical (OLAP), or large-scale unstructured analytics.
RDS (MySQL, PostgreSQL, SQL Server) gives you a managed OLTP database with primary/standby high availability, read replicas for read scaling, automated backup with point-in-time recovery, parameter templates, and storage autoscaling. Multi-AZ deployment places the standby in a different AZ.
DCS is managed Redis/Memcached for caching, session state, leaderboards, and pub/sub - high throughput, but not your system of record.
DWS is an MPP, columnar data warehouse for large-scale SQL analytics; it can query data held in OBS. DDM is distributed database middleware that shards MySQL horizontally so a single logical database can exceed one instance's capacity without rewriting the application's SQL dialect.
Data lake pattern: OBS holds raw and curated data cheaply and durably; DLI provides serverless SQL/Spark for ad-hoc and elastic analytics without cluster management; MRS provides a managed Hadoop/Spark/HBase ecosystem when you need the full open-source stack; CDM moves data between sources and the lake; DataArts Studio handles ETL, governance, and lineage; CSS serves search workloads.
Traps
DWS is not for OLTP and RDS is not for petabyte analytics - questions deliberately swap them. DCS is a cache: losing it must not lose business data. Read replicas are eventually consistent, so reporting on them can show stale values. DDM is sharding middleware for OLTP, not a SQL-on-Hadoop engine. A data lake assumes storage and compute are decoupled and scaled independently.
Rule of thumb
Small OLTP → RDS. Very large or sharded OLTP → DDM/GaussDB. Cache → DCS. Warehouse-grade analytics → DWS. Raw data plus elastic ad-hoc queries → OBS + DLI. Full Hadoop ecosystem → MRS.