← Module 02: Designing the architecture MODULE 02 · DESIGNING THE ARCHITECTURE · 45 MINUTES

Designing the architecture

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

Four layers, four concerns that cross them all

  1. 1 EXPERIENCEWeb, mobile, user journeys, accessibility
  2. 2 APPLICATIONAPIs, business rules, workflows, background jobs
  3. 3 DATA AND INTEGRATIONDatabases, storage, events, third-party services
  4. 4 INFRASTRUCTURECloud, hosting, networking, deployment

Security, observability, cost and governance apply to every layer. A real product may combine layers in one application.

THINK LIKE A CTO · MODULE 02 · ARCHITECTURE 02

The building blocks, in plain English

  1. FRONTENDWhat people see and use, in a browser or app
  2. BACKENDThe rules and the work, out of sight
  3. DATABASEWhat must be remembered, safely
  4. APISAgreed ways for software to talk to software
  5. AUTHENTICATIONProving who someone is, and what they may do
  6. INFRASTRUCTUREThe servers, networks and platforms it runs on
  7. INTEGRATIONSOther companies’ services you depend on

You don’t need to build these. You need to know which ones you depend on, and who is responsible for each.

THINK LIKE A CTO · MODULE 02 · ARCHITECTURE 03

Four architecture styles

  1. MONOLITHOne application, one deployment. Simple to build and run; can become tangled
  2. MODULAR MONOLITHOne application with clear internal modules. The usual best start
  3. MICROSERVICESMany small services, deployed separately. Scales teams; costly to operate
  4. SERVERLESSFunctions run by the cloud on demand. Little to manage; harder to test, risk of lock-in

Choose the simplest style that meets your priorities. You can split a well-built modular monolith later; merging microservices back is painful.

THINK LIKE A CTO · MODULE 02 · ARCHITECTURE 04

Scalability is not the same as complexity

Designing for credible growth

  • A target from the business: 10,000 tutors in 18 months
  • Measure first: load tests, real usage, the slowest pages
  • Scale the bottleneck you find, with the simplest fix

Designing for imagined growth

  • “What if we’re the next Uber?”
  • Distributed systems, queues and clusters before the first customer
  • Months of cost and operational burden for traffic that never comes

A good CTO designs for credible growth and avoids unnecessary infrastructure, cost and operational burden.