Skip to main content

15 posts tagged with "architecture"

View all tags

Lambda Architecture

· 2 min read

Why Use Lambda Architecture?

To address the three issues brought by big data:

  1. Accuracy (good)
  2. Latency (fast)
  3. Throughput (high)

For example: The problems of scaling web browsing data records in a traditional way:

  1. First, use a traditional relational database.
  2. Then, add a "publish/subscribe" model queue.
  3. Next, scale through horizontal partitioning or sharding.
  4. Fault tolerance issues begin to arise.
  5. Data corruption phenomena start to appear.

The key issue is that in the AKF Scaling Cube, ==having only the X-axis for horizontal partitioning of one dimension is not enough; we also need to introduce the Y-axis for functional decomposition. The lambda architecture can guide us on how to scale a data system==.

What is Lambda Architecture?

If we define a data system in the following form:

Query=function(all data)

Then a lambda architecture is:

Lambda Architecture

batch view = function(all data at the batching job's execution time)
realtime view = function(realtime view, new data)

query = function(batch view, realtime view)

==Lambda architecture = Read/Write separation (Batch Processing Layer + Service Layer) + Real-time Processing Layer==

Lambda Architecture for big data systems

Thinking Software Architecture as Physical Buildings

· One min read

What is architecture?

Architecture is the shape of the software system. Thinking it as a big picture of physical buildings.

  • paradigms are bricks.
  • design principles are rooms.
  • components are buildings.

Together they serve a specific purpose, like a hospital is for curing patients and a school is for educating students.

Why do we need architecture?

Behavior vs. Structure

Every software system provides two different values to the stakeholders: behavior and structure. Software developers are responsible for ensuring that both those values remain high.

::Software architects are, by virtue of their job description, more focused on the structure of the system than on its features and functions.::

Ultimate Goal - ==saving human resources costs per feature==

Architecture serves the full lifecycle of the software system to make it easy to understand, develop, test, deploy, and operate. The goal is to minimize the human resources costs per business use-case.

Designing very large (JavaScript) applications

· 3 min read

Very Large JS App = a lot of developers + large codebase

How to deal with a lot of developers?

empathy

What is a ==senior engineer==? A team of senior engineers without junior engineers is a team of engineers

  1. being senior means is that I’d be able to solve almost every problem that somebody might throw at me.
  2. make the junior engineers eventually be senior engineers.

what’s the next step of a senior engineer?

  1. senior: “I know how I would solve the problem” and because I know how I would solve it I could also teach someone else to do it.
  2. next level: “I know how others would solve the problem “

good programming model

how people write software, e.g. react/redux, npm. Here comes a model that affects all large JS apps - code splitting.

  1. People have to think what to bundle and when to load
  2. ==route based code splitting==
  3. But, what if it is not enough?
    1. lazy loaded every single component of our website
    2. How does Google do? split them by rendering logic, and by application logic. ==simply server side render a page, and then whatever was actually rendered, triggers downloading the associated application bundles.== Google does not do isomorphic rendering - no double rendering

How to deal with a large codebase?

==Code Removability/Delete-ability==

e.g. CSS is bad in code removability

  1. one big css file. There is this selector in there. Who really knows whether that still matches anything in your app? So, you end up just keeping it there.
  2. People thus created CSS-in-JS

==avoid central configuration of your application at all cost==

  1. Bad example
    1. central routes configuration
    2. central webpack.config.js
  2. Good example
    1. decentralized package.json

avoid central import problem: router imports component A, B, and C

  1. to solve this problem, do ==“enhance” instead of “import”==
  2. However, developers still have to decide when to enhance and when to import. Since this might lead to very bad situations, we make “enhance” illegal, nobody gets to use it–with one exception: generated code.

avoid base bundle pile of trash

  1. e.g. base bundle should never contain UI code
  2. Solve this problem with forbidden dependency tests
  3. ==most straight forward way must be the right way; otherwise add a test that ensures the right way.==

Be careful with abstractions

We have to become good at finding the right abstractions: Empathy and experience -> Right abstractions