<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on Umit Unal</title><link>https://umitunal.net/tags/architecture/</link><description>Recent content in Architecture on Umit Unal</description><generator>Hugo</generator><language>en-us</language><copyright>© 2020 Umit Unal.</copyright><lastBuildDate>Sun, 09 Aug 2026 22:25:00 +0300</lastBuildDate><atom:link href="https://umitunal.net/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>ScaleSense: Design for Scale Before You Build</title><link>https://umitunal.net/2026/08/scalesense-design-for-scale-before-you-build/</link><pubDate>Sun, 09 Aug 2026 22:25:00 +0300</pubDate><guid>https://umitunal.net/2026/08/scalesense-design-for-scale-before-you-build/</guid><description>&lt;p&gt;&lt;strong&gt;&amp;ldquo;100K users&amp;rdquo; is not a capacity plan—or even a workload.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;One hundred thousand registered users might produce 20 requests per second or
20,000. They might read tiny cached objects, run expensive analytical queries,
upload large files, or arrive together during a flash sale. The same user count
can describe systems with completely different CPU, memory, storage, network,
latency, and failure requirements.&lt;/p&gt;
&lt;p&gt;Yet architecture conversations often jump directly from a product number to a
technology. We expect 100K users, so do we need Kubernetes? Traffic will grow,
so should we add Kafka? The database might become slow, so should Redis sit in
front of it?&lt;/p&gt;</description></item></channel></rss>