Shamil's Blog. Software Engineering Processes, Android, CI, Devops.

Some reading for this week on architecture of a large systems

The good overview of using kubernetes for large finance projects by a brilliant architect Oleg Chunikhin (now CTO at Kublr) and Terry Shea, with whom I was lucky to work during early days of my career:
Making Kubernetes a Reality for Financial Services

Here's a nice description of the key moments on way working on scalable cloud system:
How to sleep at night having a cloud service: common architecture do's

A must-read about choosing a technologies:
Choose boring technology.

Labels: architecture, bookmarks, cloud, kubernetes, scalability, software architecture

It's a surprisingly common belief of using one ViewModel class in several views (screens) in modern Android Jetpack-based MVVM architecture style. In reality ViewModel cannot be shared. There're lots of arguments against reusing ViewModel. Most obvious one is that it mixes data processing logics of different screens which increases complexity of implementing and testing of ViewModels.

Do not create huge ViewModels, keep it simple. Yes, it's more classes per view, however your support and development costs are closer to linear in time.

Labels: android, architecture, mvvm, software architecture, view, viewmodel

Based on Datastax intro.

1. Distributed computation engine (aim on low latency)
2. Could be used both batch-mode or interactive
3. In-memory
4. Faster than Hadoop
5. Fault-tolerance out-of-the box

Labels: apache spark, software architecture, software engineering, spark

These notes are based on short intro.

1. cassandra has thing called "partitioning key" which is a part of the _primary key_
PK -> consistency hashing function -> value determines which Bucket (range of Hashes) it fits into -> which node we need to talk to

2. CAP theorem tradeoffs. Cassandra is Highly Available (Availability) and Partition Tolerant (Partitioning)

3. Replication. RF = 3 - factor of replication.

4. Consistency level (how many confirmations of actual nodes has written data): { All, Quorum, One }. Also can have a modifier "Local" in case of multiple data centers. We can write to different DC which could be one for OLAP one for OLTP (for different queries does not impact performance each other)

5. CL - per query; RF - per keyspace

Labels: apache cassandra, big data, cassandra, software architecture