Application Design Notes

• Don’t be afraid to write your own code, but be absolutely sure you need to
• Don't reinvent the wheel
• Learn more about your libraries and take full advantage 
• Date time calculation is hard (leap second, leap year), use trusted library 
• js-joda, momentJs, joda (java)
• 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
• Manage and store passwords securely
• Telemetry
• Common retrofitting "grunt work"
• Internationalization + localization
• Web Content Accessibility
• 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
• Use log-segmentation
• 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? 
• 23,24,25 hours days DST change must be accurate for historic dates. blog, Time Zone Database
• Applications do crash often 
• Avoid DDOS attack
• Use Rate limit
• Every feature will be misused or abused
• Isolate to avoid cascade failure 
• Use Circuit breaker
• 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