E-commerce infrastructure must do more than serve product pages. Cart, stock, payment callbacks, orders, shipping and invoicing require multiple services to remain consistent. Architecture should protect the critical sales path.
At the beginning, app, database and Redis can share one NVMe VPS. As orders, database IO, queues or deployment impact grow, separating app, database and workers becomes safer. Base the decision on p95 latency and resource measurements.
Even after a successful payment, stock, order records, invoicing and notifications should be idempotent and observable.
The bottleneck can shift over time: web during campaigns, queues during bulk integration, databases during reporting.
Avoid storing payment-card data unnecessarily; hosted or tokenized provider flows can reduce operational risk.
CPU load alone is insufficient; inspect memory, IO, connections and failed services together.
uptimefree -hiostat -xz 1 5ss -ssystemctl --failedjournalctl -p warning --since '-15 min'Measure first, then separate the largest bottleneck; avoid unnecessary microservice complexity.
No. A well-sized NVMe VDS can fit many small/mid stores; dedicated should be justified by sustained CPU/IO and isolation needs.
No. It can help with cache, sessions or queues and should be added when the architecture benefits.
Separating heavy ERP, invoicing and notification work from the payment callback can improve reliability and latency.
Share peak users, daily orders, products, integrations and database size; we can design the right VDS/dedicated topology.