When you start working with your Phoenix application, you'll inevitably start marveling about how fast your application runs, how stable it is, and how well it handles an absolute ton of incoming connections. The great thing about working with Phoenix is that all of this is just something you get for free! No drama, no confusion, your application just scales for free to an amazing level. This is a wonderful thing to think about when you're architecting a site. Typically, there is a dance that happens somewhere along the implementation of your site where you need to start thinking and planning for how you're going to scale your app for 10x/100x/1000x growth in concurrent users.

If you're hosting your application in the cloud, you might just scale by throwing a ton of money at the problem until you can start making tweaks to your application. This is a high-up-front-cost method of scaling and tends to be a cost that is difficult to reduce in the lifetime of your application. In my personal experience, what usually happens is your patterns for scale, growth, and optimization tend to run very close to parallel with each other, so as you optimize your application you may end up just keeping the same number of cloud resources enlisted; you're just able to support more concurrent users as you make those optimizations. That makes these early decisions around scaling critical, and they affect your budget very early instead of allowing your application to scale organically with more users, more business, and more money!

If you're using a dedicated data center, you may have a much tougher life in this regard. You may have limited resources available to you for scaling and you may not be able to adjust them quickly, meaning your decisions need to be based around significant amounts of capacity planning and significant engineering, design, scale, and architecture plans and designs. You might be slower to react and acquiring new hardware might be locked behind multiple levels of approvals, purchase orders, installation, configuration, and so on. That being said, you might also be able to scale up long-term at a cheaper cost.

Elixir and Phoenix thrive on concurrency and parallelism! This means your capacity planning sessions and architecture designs can be significantly simpler and cheaper, both in the long-term and the short-term! If you're running on cloud services for running your application, you'll find Phoenix runs great on nearly all of the choices out there! You can reduce your needs for scaling and avoid running up a giant monthly cloud services bill! If you're running on a dedicated data center, you'll find your purchase orders for new hardware are greatly decreased (well, at least for your application's side of things)!

Generally speaking, you won't find yourself having to obsess about the BEAM/OTP concurrency model and how to optimize your application at insane levels. Of course, we would be remiss in our duties if we didn't spend a bit of time discussing what is going on behind the scenes and how to make the model work for your application! Maybe you find yourself wanting to write a library that makes your application easier to use and more reliable or maybe you just want to understand what is going on in all parts of your application! In this chapter, we'll spend the entire time really diving into and understanding the entire model for concurrency and parallelism behind Elixir. We'll explore:

• The difference between concurrency and parallelism
• What is OTP
• What is Elixir's model for concurrency and parallelism
  • Understanding supervisors
  • Understanding applications
  • Understanding workers
• Implementing each model:
  • Starting simple with task/await
  • Actors and agents
  • GenServers
  • GenStage