Memcached - Points to ponder

Few points to watch out in Memcached implementation and testing

1. Decide between Early loading v/s Lazy loading or combination
   
2. Size of Memory & CPU (not CPU intensive)
3. Set LRU policy (will help Memory sizing)
4. Latency
5. What to cache and what to skip?
6. Identify no. of Memcached instances and banks
7. Select appropriate log levels
8. Separate & manage Memcached logs
   
9. Monitor Memcached servers (CPU, Memory,hits & misses of database and cache, etc)
   
10. Ensure code coverage to leverage caching
11. Test for thread contention
12. Identify when to use get v/s multi-get
13. Memcached allows us to scale out Application server instances. In case of multiple we need to take care of synchronization blocks (if any) used in our code.
    

Conway's Law.

This week I came across Conway's Law which says "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

I think its important to note that in a project comprising of different teams, the teams should NOT work in silo.

For e.g.
A project may consist of following teams - User interface teams (create screens), developer team (code), reporting team (develop reports) , Quality control team and the deployment/server monitoring team.

Now it may so happen that the reporting team create report wherein they write the entire logic in Stored procedures as the team would be well versed in writing procedures and interaction with the development team is limited.

In this scenario, the performance team and monitoring team may find a procedure taking up resources of database and may find it as a root cause of server slow down. But in reality, the real root cause lies in whats Conway's Law says.

If the development team and reporting team worked together then probably during the transaction itself a summary table could have been populated on which the reports could work.