The document discusses principles of designing scalable systems, emphasizing the need to prepare for both performance scaling up and instance scaling out. It highlights the importance of utilizing proper design patterns like repositories and patterns for asynchronous operations, alongside considerations for testing and integration with different authentication methods. Additionally, it advocates for a fault-tolerant architecture and the use of interfaces and dependency injection to ensure decoupled and replaceable services.

1. Design for Scale
(AKA “Design for when the @#&!% rug
gets pulled out from under you)
Doug Lampe

2. Things You Should Know
(or Learn)
• Interfaces
• Generics
• Delegates
• Lambda Expressions
• Async

3. What Does “Scale” Mean?
• Up – Add capacity/performance
• Out – Add instances

4. When Do You Scale?

5. When Do You Scale?

6. SCALING UP

7. Microsoft is Not always Your Friend
 Entity Framework
 Repository Pattern
 Authorization Provider

8. Entity Framework?
• Is this high-performance?
• Is this thread-safe?
• Do I care?
Get Data
SQL
Create
Object
Update
Object
Save
Changes
Data
SQL

9. Entity Framework?
Customer
Phone
Number
Email
Address
Customer Phone Email
Joe Blow 407-555-5555 joe123@gmail.com
Joe Blow 407-555-5555 joe.blow@job.com
Joe Blow 321-555-5555 joe123@gmail.com
Joe Blow 321-555-5555 joe.blow@job.com
Write the SQL you need when you need it

10. Repository Pattern?
• Bad Repository:
– Repository.Context
– Query(lambda)
– ExecuteSql(sql)
• Good Repository:
– Get(id)
– Save(object)
– DoSomething(key,
value)
Repository should abstract logic, not database provider

11. But what about unit testing?
• Can still abstract “store” if you want
• Do you need to test this?
return Context.Things.FirstOrDefault(x => x.Id == id);
• Or this?
var user = userService.get(userName);
var message = messageService.get(“passwordReset”, user);
emailService.sendEmal(message);

12. Authentication Provider?
• How do I create the database?
• What if I have an existing user database?
• What if I have a third party user store?
• What if I have more than one user database?
• What if I’m using a different authentication scheme?
• What if Facebook/Google/Microsoft changes their API?
• What if I don’t want to use OWIN?
• What happens when I move to .Net Core?

13. Microsoft WCF is Your Friend
• Operation Contract
– Interface defining what service can do
• Data Contract
– Class defining data to be transmitted

14. Microsoft Azure is Your Friend

15. Microsoft Azure is Your Friend
Queue API:
• Create
• Exists
• Delete
• AddMessage
• DeleteMessage
• GetMessage
• PeekMessage
• UpdateMessage
• Clear

16. Async is Your Friend
• When you call async processes
• When you use unmanaged resources
• NOT for every single API/HTTP call

17. SCALING OUT

18. GUIDs are Your Friend
• Identity fields:
– Local to database instance
– Not easily replicated
– Smaller
• GUIDs:
– Portable
– Bigger

19. Strings are Your Friend
• Use strings for IDs in POCOs

20. PUTTING THE PIECES TOGETHER

21. How Many Projects Do You Need?
• More than 1

22. Rule #1: Use Projects to Force SOC
Contracts
• Interfaces
• POCOs
API
• “Orchestration”
Web
• Configuration
• Dependency Injection
Services
• Interface Implementation
App
• UX

23. Rule #1: Use Projects to Force SOC
Contracts
• Interfaces
• POCOs
API
• “Orchestration”
Web
• Configuration
• Dependency Injection
Services
• Interface Implementation
App
• UX
API shouldn’t care how services
are implemented

24. Rule #1: Use Projects to Force SOC
Contracts
• Interfaces
• POCOs
API
• “Orchestration”
Web
• Configuration
• Dependency Injection
Services
• Interface Implementation
App
• UX
API shouldn’t care about how it is
hosted

25. Rule #1: Use Projects to Force SOC
Contracts
• Interfaces
• POCOs
API
• “Orchestration”
Web
• Configuration
• Dependency Injection
Services
• Interface Implementation
App
• UX
Application should be easily
replaced or duplicated

26. Rule #2:
• Be fault tolerant
• Use lots of “queues”
• Use “enterprise” queues to decouple nodes

27. Rule #3:
Know What “Done” Means
• When API call completes?
• When data is persisted?
• When transaction is complete?
Scale “Up” by letting users know when they are done
(even if there is more work to do)

28. Rule #4:
• Assume all API calls are being made
maliciously

29. Rule #5:
• If you can’t decide the “right” way to do
something, figure out how to make sure it
doesn’t matter how you do it.

30. QUESTIONS?