แอปพลิเคชันธุรกิจแบบ web-based ส่วนใหญ่มี request flow แบบเดียวกัน คือ request จาก browser จะไปที่ web server จากนั้นไปที่ application server และสุดท้ายไปที่ database server แม้ request flow แบบนี้จะทำงานได้ดีกับจำนวน concurrent user ที่น้อย แต่ bottleneck จะเริ่มปรากฏขึ้นเมื่อ concurrent user load เพิ่มขึ้น โดยเกิดที่ web-server layer ก่อน ตามด้วย application-server layer และสุดท้ายคือ database-server layer
การตอบสนองทั่วไปเมื่อ user load ที่เพิ่มขึ้นทำให้เกิด bottleneck คือการ scale out web server ซึ่งค่อนข้างง่ายและ ราคาไม่แพง และบางครั้งก็ได้ผล อย่างไรก็ตาม ในกรณีส่วนใหญ่ที่ user load สูง การ scale out web-server layer เพียงแค่ย้าย bottleneck ลงไปที่ application server การ scale application server อาจซับซ้อนและแพงกว่าการ scale web server และมักย้าย bottleneck ลงไปที่ database server ต่อ ซึ่ง scale ยากและแพงกว่าเดิมอีก แม้จะสามารถ scale ฐานข้อมูลได้ สุดท้ายแล้วสิ่งที่ได้ก็คือ topology รูปสามเหลี่ยม โดยส่วนที่กว้างที่สุดของสามเหลี่ยมคือ web server (scale ง่ายที่สุด) และส่วนที่แคบที่สุดคือฐานข้อมูล (scale ยากที่สุด) ดังแสดงใน Figure 16-1 .
ในแอปพลิเคชันที่มี volume สูงและมี concurrent user load จำนวนมาก ฐานข้อมูลมักจะเป็นปัจจัยจำกัดสุดท้ายว่า แอปพลิเคชันจะประมวลผล transaction ได้พร้อมกันกี่รายการ แม้ caching technology และผลิตภัณฑ์สำหรับ scale ฐานข้อมูล ต่าง ๆ จะช่วยได้บ้าง แต่การ scale out แอปพลิเคชันทั่วไปเพื่อรองรับ load ระดับสุดขั้วยังคงเป็นเรื่องยากมาก
Figure 16-1. ขีดจำกัดด้าน scalability ภายใน topology แบบ web-based ทั่วไป
space-based architecture style ถูกออกแบบมาโดยเฉพาะเพื่อแก้ปัญหาที่เกี่ยวข้องกับ scalability, elasticity และ concurrency ระดับสูง นอกจากนี้ยังเป็น architecture style ที่มีประโยชน์สำหรับแอปพลิเคชันที่มี concurrent user volume ที่แปรผันและคาดเดาไม่ได้ หลายครั้งการแก้ปัญหา scalability ที่สุดขั้วและแปรผันด้วยวิธีทาง architecture นั้นดีกว่า การพยายาม scale out ฐานข้อมูลหรือใส่ caching technology เข้าไปใน architecture ที่ไม่สามารถ scale ได้ดีอยู่แล้ว