← Module 04: Security, resilience and scalability MODULE 04 · SECURITY, RESILIENCE AND SCALABILITY · 40 MINUTES

Security, resilience and scalability

Present slides Full screen, one slide at a time · 6 slides
THINK LIKE A CTO · MODULE 04 · SECURITY 01

Threat modelling in four questions

  1. WHAT ARE WE BUILDING?Your component diagram, and where the valuable data lives
  2. WHAT CAN GO WRONG?Who might attack or misuse it, and what they would want
  3. WHAT WILL WE DO ABOUT IT?Controls in proportion to the risk: prevent, detect, recover
  4. DID WE DO A GOOD ENOUGH JOB?Test it, review it, and repeat when the product changes

Threat modelling is structured worrying: done early, on paper, while changes are cheap.

THINK LIKE A CTO · MODULE 04 · SECURITY 02

Six controls every product needs

  1. ACCESS CONTROLStrong sign-in, two-factor for staff, least privilege everywhere
  2. ENCRYPTIONIn transit always; at rest for sensitive data and backups
  3. SECRETSPasswords and keys kept in a vault, never in code or chat
  4. BACKUPSAutomatic, encrypted, and restored in a test at least once
  5. LOGGINGA record of who did what, kept safely, watched for oddities
  6. UPDATESDependencies and platforms patched on a schedule

Data protection law expects security appropriate to the risk. For children’s, health or financial data, take specialist advice.

THINK LIKE A CTO · MODULE 04 · RESILIENCE 03

How much failure can the business survive?

  1. AVAILABILITYHow often it must be up: 99.5% allows about 3.6 hours down a month
  2. RECOVERY TIME (RTO)How long you can be down before real harm
  3. DATA LOSS (RPO)How many minutes of data you could afford to lose
  4. MONITORINGHow you find out before your customers tell you

These are business decisions with technical consequences. Each extra nine costs more than the last.

THINK LIKE A CTO · MODULE 04 · SCALABILITY 04

Capacity planning without fortune-telling

Do this

  • Estimate the credible peak from business targets
  • Load-test before each growth step, on a copy
  • Watch the slowest pages and the busiest queries

Not this

  • Guess “millions of users” and design for it
  • Wait for the first outage to find the limit
  • Add servers when the real problem is one slow query

Measure, find the bottleneck, fix the cheapest thing. Repeat at each growth step.