Skip to main content

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
  • 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 (Telemetry)
    • Monitor the entire system end to end the same way as user see it 
    • Monitor the health of individual component 
  • 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.

Recently I found this issue while writing code snippet in "JSFiddle". And after searching, found this was happening because of new feature added in "Chrome 46+". But at the same time Chrome doesn't have support for "allow-modals" property in "sandbox" attribute. Chromium issue for above behavior: https://codereview.chromium.org/1126253007 To make it work you have to add "allow-scripts allow-modals" in "sandbox" attribute, and use "window.alert" instead of "alert". <!-- Sandbox frame will execute javascript and show modal dialogs --> <iframe sandbox="allow-scripts allow-modals" src="iframe.html"> </iframe> Feature added: Block modal dialog inside a sandboxed iframe. Link: https://www.chromestatus.com/feature/4747009953103872 Feature working Demo page: https://googlechrome.github.io/samples/block-modal-dialogs-sandboxed-iframe/index.html

How to store user password at server!!!

Trick is, you should never store user password… never ever. Now the real question is, then how to authenticate and authorize the user with password. And answer is when user enter the password, we should encrypt the password and store the hints. So next time when user enter the password we follow the same process and compare hints, if both hints are same then password is matched, else it is wrong password. Next question will be, what kind of hints, and how to generate these hints. In simple term hints are the obfuscated and fragmented form of user password. And very important part is hints generation process, which have to be collision resistant , means there will be very less possibility to find the data which generate same hints (like Cryptographic hashing functions ). Below is the simple checklist of password hashing and storing, which you should always keep in mind. PS You're Probably Storing Passwords Incorrectly Storing Passwords - done rig