Skip to main content

Scalability And Performance Split Your Data and Simplify

Introduction

Here are a few guidelines for supporting scalability and performance in your systems.
  1. Simplify — Simplify your code and design, you will gain from it an easier to understand and a scalable system, your life will be scalable, the more complex it is the less it’s possible to scale it out and the more complex your life is. Of Course if its not possible to simplify do not we are sane people, but many times we only think its not possible to simplify while it’s possible, so do ourself a favour and put some effort on this.
2. X Axis Duplicate Data Create multiple read only db’s or clones for your data and thus scale your reads. You can then use a read query to read across multiple copies of your data thus less strain on your servers.
3. Y Axis Split on business your data like microservices also in db level not only in service level, different roles, different db’s. Do you sell both underwear and have another line of business for atomic energy manufacturing? what do you think of having 2 db’s or more, or just splitting your data you could still have a single db, just make sure you split things.
4. Z Axis Split on same - If you have multiple customers split on customer id, you can put smaller customers on same shard and larger one on different. Be sure you split on categories that makes sense for an even split and not for example on location, in this case if 80% of your customers are from a certain place you didn’t split ok.
5. 3 Data centers rules — If you had only 2 data centers you need 200% capacity if one goes down in order to serve 100% capacity, if you have 3 data centers you need total of 150% so two of them would make 100% capacity if one of them goes down.
6. Remember storage alternatives — Remember you have different storages such as file storage such as `ceph` (don’t forget the file system), nosql, wide column storage such as cassandra and relational. Column storage usually provide automatic row sharding and asynchronous replication with eventual consistency, column split requires more of manual intervention.
7. Consistency - If you increase consistency for example on nosql then operations such as `getSomething` would require to contact all nodes to make sure they return the recent and greatest version.
8. Firewalls are like locks — You lock your main door but you don’t lock internal doors is that right? Credit card request through lock but not image request. Don’t overuse your firewall, it’s complex enough without it.
9. Really need a transaction? When you pass money from one customer to another do you really need a transaction? Consider all options, usually when you start considering event sourcing you see you can compromise without transactions.
10. Dont read validate your write Have you just wrote something to disk/cache/db? don’t reread it in order to validate it your servers have more useful things to do.

Resources



Comments

Popular posts from this blog

Dev OnCall Patterns

Introduction Being On-Call is not easy. So does writing software. Being On-Call is not just a magic solution, anyone who has been On-Call can tell you that, it's a stressful, you could be woken up at the middle of the night, and be undress stress, there are way's to mitigate that. White having software developers as On-Calls has its benefits, in order to preserve the benefits you should take special measurements in order to mitigate the stress and lack of sleep missing work-life balance that comes along with it. Many software developers can tell you that even if they were not being contacted the thought of being available 24/7 had its toll on them. But on the contrary a software developer who is an On-Call's gains many insights into troubleshooting, responsibility and deeper understanding of the code that he and his peers wrote. Being an On-Call all has become a natural part of software development. Please note I do not call software development software engineering b

SQL Window functions (OVER, PARTITION_BY, ...)

Introduction When you run an SQL Query you select rows, but what if you want to have a summary per multiple rows, for example you want to get the top basketball for each country, in this case we don't only group by country, but we want also to get the top player for each of the country.  This means we want to group by country and then select the first player.  In standard SQL we do this with joining with same table, but we could also use partition by and windowing functions. For each row the window function is computed across the rows that fall into the same partition as the current row.  Window functions are permitted only in the  SELECT  list and the  ORDER BY  clause of the query They are forbidden elsewhere, such as in  GROUP BY ,  HAVING  and  WHERE  clauses. This is because they logically execute after the processing of those clauses Over, Partition By So in order to do a window we need this input: - How do we want to group the data which windows do we want to have? so  def c

Building Secure and Reliable Systems

A recent book was published this year by Google about site reliability and security engineering, I would like to provide you a brief overview of it and incorporate my own analysis and thoughts about this subject while saving you some time from reading, at least part of it. Take a few of your customers and ask them, what are the top 5 features on my product that you like.  The answer that you are likely to get is, I really like how polished the UI is, or the daily report I get by mail is just fantastic, or since I started using your product I was able to save one hour a day my productivity got up and the share /chat button on document that you added recently is doing a great job. Your customers are very unlikely to answer the question of what top 5 features of my product do you like with I really like its security or I really like that we lost no chat messages since I started using it.  No real customer will even think of it, moreover, assuming you did a very good job, they won&#