Application Design Notes



  • Don’t be afraid to write your own code, but be absolutely sure you need to
  • Simple is better than perfect (nearly) every time
    • If you can deliver a sub-optimal solution (that solves the problem but has known limitation) in a week instead of a full featured one in a month DO, IT
    • Simple system are
      • Easy to reason about 
      • Easy to debug
      • Easy to refactor
      • Easy to learn
    • Simple doesn't mean you skip good engineering, but you can use duct tape.
  • Build things the right way from the start, refactoring is hard and expensive
    • Security
    • Cutout unimportant corners
    • Common retrofitting "grunt work"
      • Internationalization + localization
      • Factoring and styling HTML UI
      • Adding unit test to an existing codebase
  • LOG LOG LOG Log, but do it right
    • We spend lot of time reading and processing log
    • When error occur log as much context as possible
    • Make changing logging verbosity cheap and easy to update at same time
  • Build Profiling into your product code
    • Performance problem usually occur first time in production
    • Many large-scale production enviroment are hard to replicate 
      • Have a way to access critical profiling info for production process
      • Custom HTTMP/Tenet interface
      • Shared memory window
  • Monitor your product end to end not just sub system
    • Monitor the entire system end to end the same way as user see it
    • Monitor the health of individual component (like unit testing)
  • Avoid platform specific feature wherever you can 
    • Migration can be very-very expensive same time impossible
    • Running testing on multiple platforms will expose bugs faster
  • Write your code like you trust no one 
    • Always test precondition before function execute 
    • If something should be in give state, test for it
    • Sanitize input and output
    • Leave these tests in production code
  • Choose your dependencies carefully
    • Every dependency is a liability. You have to fix (or get fix) any error in them
    • Prefer open source to close source 
      • At least you have the option of fixing a problem
    • Dependency often increase complexity 
      • Build
      • Packaging 
      • Licensing
      • Security, verification (XSS, SQL injection, buffer overflow..)
  • If you can pre-generate something, do it
    • Lookup table are an underutilized secret weapon 
    • Memory is cheap
    • Pre calculate result if
      • The input to a computation is known to be in given range
        • The number of different results is relatively small (<1 Billion)
      • Calculation is sufficiently complex
        • Example - Pre-compute the time zone conversion from UTC to all time zone for all hours from 01/01/1991 to 12/31/2020
          • Why this is complex to calculate? 
  • Applications do crash often 
    • Avoid DDOS attack
    • Every feature will be misused or abused
    • Isolate to avoid cascade failure 
    • No such thing as a long-lived process
      • If hardware fails or power removed your process will crash
      • Design system to be fault tolerant to process re-start
        • All state must be external to process
        • Try to keep services and process stateless 
    • Keep sever stateless 
      • One app server should not affect any other server
      • Server will be easy to scale 
      • Separate cache service from other server to avoid resource contention
  • Cache appropriately  
    • Data, metadata, configuration, static data 
  • Store redundant
  • Partition by functions
    • Allow people to work independently on features
  • Split horizontally
    • If you can’t split, you can’t scale 
    • Use standard load balance to route incoming traffic 
      • Because application service created equal and not retain any transaction state
  • Decouple functions asynchronously 
    • If A call B synchronously, A & B are tightly couple. So, if B is down then A is down. 
    • A should be integrated B with asynchronously (with queue, multicast message, path processing, event driven architecture)
    •  Avoid synchronous coupling as much as possible
    • Move processing to asynchronously flow
      • Asynchronously flow example can be 
        • Activity tracking, billing, settlement, reporting, email
  • Use Feature Toggling to deliver new functionality to users rapidly but safely.
  • Virtualize at all level
    • Virtual IP for DBs
    • Virtual IP for load balancer 

Comments

Popular posts from this blog

ERROR: Ignored call to 'alert()'. The document is sandboxed, and the 'allow-modals' keyword is not set.

CSS Specificity

JavaScript [ExtJs3]: EditorGridPanel Read-Only (dynamically)