Please enable JavaScript.
Coggle requires JavaScript to display documents.
Interview-map
buy Vuong a starbuck :kissing:, database, HEAP/STACK AREA,…
-
database
improve DB performance
optimize queries
- write efficient SQL (avoid select */complex join...)
- query profilling: EXPLAIN select * from...
- well schema design
- indexing
- like a db roadmap, instead of scanning an entier table, db engine use index to locate required row
structure
- B-tree index (MC)
- hash index
- bitmap
- full-text index
type
- primary index( primary key)
- second index (non-primary key col)
- unique index
- composite index
- partial index
strategy
- column frequently queried: where, group by, order by, join...
- many unique values: email
- composite for multiple columns
trade off
- performance ( slow for write operation)
- disk space
-> avoid over-indexing / column rarely queries
- db configuration: (connection pooling, memory allocation, query cache)
- monitor, analyze
- caching for repetitive read queries
(view/materialize view)
apply best practice
- avoid lock
- connection optimization
- regular rebuild index to maintain
- optimize data type (use INT instead BIGINT)
database transaction
ACID principle:
- Atomicity:- consistency
- isolation:
consistency
- ensure db move from 1 valid state to another
- số tiền trong ví luôn chính xác sau mỗi giao dịch
isolation
- ensure multiple transaction running concurrency not affect each other
- 2 người mua hàng k ảnh hưởng đến nhau khi thanh toán
- database transaction must complete task independently from other
- multiple transaction - concurrent transaction
-> dirty read (read_uncommitted)
Atomicity - all or nothing
- all txn must succeed or failed together
- mua hàng chỉ thành công nếu trả đủ tiền & nhận đủ sản phẩm
durability
- once txn is committed, its changes are permanent
- đơn hàng đc ghi nhận ngay cả khi mất điện
-
- class level (prefer)
- method level
locking behavior is same
- class level shares same a single connection
- method level require its own db connection -> sometimes lead to db connection exhausted
-
transaction
- set of SQL queries that are executed as a single logical unit of work
entity
- represent a table in the database
relationship
fetchType:
- lazy: load on demand
- eager: loads it immediately
-
n+1 issue:
- app executes 1 query to fetch parent entity and then executed N additional queries to fetch related data
- joinfetch : select from user u join fetch u.orders
- pros: simple and effective
- cons: hard code
- entityGraph - recommend
- pros: simple, resuable, maintainable
- cons: limit flexibility for complex join
- batch Fetch
- cons: not a JPA standard
- native SQL:
- pros: full controll
- cons: tightly coupled to db schema
-
concept:
- JPA - Oracle specification - mapping Java to ORM
- Hibernate: JPA provider (ORM framework)
- Spring Data JPA: (Spring framework = JPA + Hibernate)
hibernate:
- JPA provider
- Hibernate query language
- caching (level 1, level 2)
-
- avoid using transaction across micro services
- if needed: TWO PHASE COMMIT
- load data -> ram
- commit change in ram
- commit -> disk
HEAP/STACK AREA
STACK ST
Stack memory tạm thời chứa local variable của method được gọi, và sẽ xóa đi khi method hoàn thành
-
-
-
-
HEAP AREA
quản lý theo concept
- young generation
- old generation
-
-
-
-
-
Spring
Alternative Spring frame work
dependency injection
- google juice/ google dagger
What
Spring FW is just a dependency injection container offering a couple of convenience layers(database, security, aop...) added on top
- help to build java application faster and convenience
- just focus to implement business logic instead of boilerplate code
achieve loose coupling through:
How
-
ApplicationContext
manage lifecycle of beans, resolves dependencies, ...
bean
scope
-
prototype
bean is not shared, new bean instance is created every time it is requested from IOC
-
-
customer Scope
- implement Scope interface
-
lifecycle
bean init
populate properties
- constructor injection
- setter injection
-
-
responsibility
-
-
dependency injection
- constructor
- Autowire (field injection)
- setter
constructor - mc
pros:
- requires all dependencies upfront then inject directly to constructor -> avoid overheating using reflection
- better for unit test
setter injection cũng k sử dụng reflection: NHƯNG:
- private EmailService emailService;
- final KHÔNG HOẠT ĐỘNG với setter injection vì:
- Setter injection chạy sau constructor -> lúc này class có final mà không được khởi tạo trong constructor -> chúng sẽ k hợp lệ
- private EmailService emailService
-
-
-
WHY
Java FRAMEWORK for building ENTERPRISE-level app
- focus task/business instead of boilerplate code
key feature
- IoC
- AOP
- TransactionManagement
- Data access
- Security
testing with spring
tool
- performance test: Jmeter
- automation: selenium, postman, cucumber
test strategy
stage
acceptance stage
- deploy prd, stg
- performance test, security test, compliance test
-
commit stage
- build, test, package -> release artifact
latency metric:
request faster than expected
- P90 -> optimize to most user
- P95 -> good experience for a larger customer
- P99: fix rare issue for last 1%
testing level
- unit test
- integration test
- system test
- UAT
CONCEPT
SOLID
- single responsibility: a class should have one and one reason to change, it means a class should have a single job.
- invoicePrinter should only do print.. not calculating the total price
- open/close: a class should be open for adding new feature but close for modifying existing code
- adding new method instead of changing existing method by extending the class.
- liskov substitution: subclass should be able to replace their parent class without affecting the program.
- if Bird has method fly(), a subclass Penguin should not break by failing implement flying (since Penguin cannot fly.. it shouldn’t inherit Bird)
- interface segregation: instead of creating a large interface, break it down to smaller
- dependency inversion: high-level class should depend on abstraction/interface rather than the low-level class / concrete implementation
- class OrderProcessor should depend on PaymentProcessor instead of the impl - PaymentProcessorImpl
ACID principle:
- Atomicity:- consistency
- isolation:
consistency
- ensure db move from 1 valid state to another
- số tiền trong ví luôn chính xác sau mỗi giao dịch
isolation
- ensure multiple transaction running concurrency not affect each other
- 2 người mua hàng k ảnh hưởng đến nhau khi thanh toán
- database transaction must complete task independently from other
- multiple transaction - concurrent transaction
-> dirty read (read_uncommitted)
Atomicity - all or nothing
- all txn must succeed or failed together
- mua hàng chỉ thành công nếu trả đủ tiền & nhận đủ sản phẩm
durability
- once txn is committed, its changes are permanent
- đơn hàng đc ghi nhận ngay cả khi mất điện
-
CAP
- trade off when designing a distributed system
- can achieve at most two of 3 properties at the same time
-> cannot achieve all 3 propertis -> must make a trade off
consistency (read)
- all nodes return same data at any given time
- in bank, if you transfer money from A to B, every query should reflect the updated balance immediately
-
availability (read/write)
- every request (read/write) receives a response, regardless of wheter it is the most recent data
- if 1 server goes down, system continues to provide response by routing them to other server
-
partition tolerance
- system continues to operate despite network failure (partitions) that prevent communication between nodes.
- if network link between 2 data centers is broken, both side still function independently
-
-
OOP
- everything java is object
- making it modular and easier to maintain and extend
encapsulation
- protect method, property by restricting/controlling data access using access modifier (public, protected, ...)
inheritance
- allow child class extend/inherit property/method from parent class.
- promote reuse and hierarchical classification
polymophism
- provide flexibility, allowing method perform different tasks based on the object that invoke them
- overloading/overriding
abstraction
- show only essential feature and hide unnecessary details
- abstract class / interface
-
OAUTH 2
- authorization framework
- allow app access resource (user data) on behalf of a user
- without sharing user credentials
- ex: logging 3rd app using facebook, gmail
key concept
- user login authorization server then approve client's access request
- authorization server issue access token
- client use access token to make request to resource server
- resource server (google Drive)
- server holds user's data
- client (photo editing app)
- app request access on behalf of user
- authorization server (gg login service)
- server authen user and issue token to client
- access token
- refresh token
- user (resource owner)
- user who own data/resource
grant type
authorization code (login with FB)
- user click login with fb
- user login and approve request
- fb send authorization code to editing app
- app exchange code for access token
- app access data
client credentials
- 2 server communication without user involved
- backend service access to cloud API (using token)
PKCE not recommend
- token is issued directly to client without authorization code exchange
device code
- smart tv request device code from authorization server
- user enter code on another device (mobile)
- server issue access token
refresh token
- still authorization code (access token + refresh token)
keycloak
- manage user accounts
- support OAuth2 + OpenIDConnect (OIDC)
-
Multi Thread
framework:
- fork join
- competable future
Thread
- smalles unit of execution in a process
- 1 process can have multiple threads running concurrently
threadpool:
- collection of pre-created threads that are used for executing tasks
- reusing many time
- creating thread is very expensive -> avoid destroy
- kitchen (thread pool) have 5 chef (threads)
advantages:
- efficient resource management
- control over concurrency
- improve responsiveness
key component:
- core pool size
- maximum pool size
- work queue
- thread factory
- rejection policy
create threadpool
(threadpool executor)
- fixed threadpool executor
- cached
- ...
threads are expensive
- creation cost
- context switching
- management overhead
life cycle
- new
- runnable
- non runnable: iddle
- terminated
-
-
JAVA core
-
hashCode & equal
Object define equal(), hasCode()
override when
- compare object by value instead of address
-
-
HashMap dataStructure <K,V>
-
-
hash table
- data structure store key-value pair
- use hash function to compute an index from key
- enabling fast retrieval, insert, delete O(1)
key characteristics:
- keys are hashed
- handle collisions
- immutable key
hashMap
implementation of hash table in Java
- allow null keys / values
- not thread safe
- unordered
Cloud native
properties:
- scalability
- loose coupling
- resilience
- observability
- manageability
-
- container
- orchestration - scaling container
-
-
-
observability
- monitoring
- alerting / visualization
- distributed tracing
- log aggregation / analytics
manageability:
- spring cloud config server
- k8s configmap / secrets
...
cloud native pattern
-
principles:
- 1 codebase, 1 app
- API first
- stages: design, build, release, run
- configuration, credentials, code
- logs
- graceful shutdown
- backing services: kafkaesque, smtp, ...
- env parity: dev, stg, prod
- concurrency
- telemetry
- security (authen/author)
what
- modern approach to building, deploy, running app on cloud
design pattern
- reusable solution to common software design problem
- provide template for structuring and implementing code
creation pattern
- focus on object creation mechanism
singleton
- ensure a class had only 1 instance and provide 1 global entry point to access it
- datase conection pool, configuration manager
- private static Singleton instance;
- private SingleTon(){};
- public static synchronized SingleTon getInstance() {
if instance == null -> instance = new SingleTon()
return instance}
factory pattern
- interface for creating object but let subclass define which class to be init
- interface Shape { void draw() }
- class Circle implement Shape{}
- class ShapeFactory{
public Shape getShape(string type) {
if type equal "CIRCLE" return new Circle() }
builder
- constructs complex object step by step
- creating object with many optional params (stringBuilder)
structure pattern
- focus on how to organize class/object to larger form/structure
adapter
- act as a bride between 2 incompatible interface
- allow system work together event if they have different API
- interface MediaPlayer { void play (audioType, fileName) }
- interface NewMediaPlayer {void playMp4(fileName)}
- class MediaAdapter implement MediaPlayer {
void play (audioType, fileName) {
if audioType == "MP4" newMediaPlayer.playMp4 (fileName)
decorator
- dynamically add function to an object without modifying its code
- interface Coffee {cost(), description()}
- class BasicCoffee implement Coffee {cost = 5, desc = basic coffee}
- class CoffeeDecorator implement Coffee {protected Coffee coffee; cost = coffee.cost; desc = coffee.desc}
- class MilkDecorator extend CoffeeDecorator { public MilkDecorate(coffee) super(coffee); cost = super.cost + 2.0; desc = super.desc + ",milk" }
- class SugarDecorator extend CoffeeDecorator { public SugarDecorate(coffee) super(coffee); cost = super.cost + 1.0; desc = super.desc + ", sugar" }
- class void main CoffeeShop { coffee = new BasicCoffee (); coffee = new MilkDecorator(coffee) ; coffee = new SugarDecorator(coffee) }
proxy
- control access to another object
- handle cross cutting concern: lazy load, security, logging...
- interface Image { display () }
- class RealImage implement Image {}
- class ProxyImage implement Image {
private RealImage;
override display() {if realImage == null {realImage = new RealImage(}}
realImage.display
behavior pattern
- focus on interaction and communication between object
observer
- define 1-to-many dependency between object
- 1(subject), many(observers)
- all observers wll be notified automatically
- ex: stock trading app
- interface Observer() {void update(symbol, price) }
- class Stock {List<Observers> observers; symbol, price; void addObs() observers.add(obs);void notifyObservers() for obs range observers -> update(symbol, price)
- class User implement Observer {name; void update(symble, price)}
- class StockMarketApp {apple = new Stock('APPL'); user1 = Alice, user2 = BoB; apple.addObs(user1).addObs(user2);
apple.setPrice(100) // notifiy all user}
strategy
- define family of algo, encapsulate them, make them interchangeable at runtime
- build payment system where user can choose between credit card, paypal, ...
- interface PaymentStrategy {void pay()}
- class CreditPayment implement PaymentStrategy { pay())
- class PaypalStrategy implement PaymentStrategy{ pay()}
- class PaymentContext {paymentStrategy; setPaymentStrategy(); void pay(strategy.pay()}
- PaymentSystem { paymentContext = new PaymentContext;
context.setPaymentStrategy(new Credit).pay(100)
context.setPaymentStrategy(new Paypal).pay(200)
JVM
mainly structure
Class Loader
-
linking
verification, preparation
-
allocates memory for class variable, and default values
-
JVM memory
method area
class level information
class name, parent class name, method, variable...
-
stack area
every thread, JVM create one run-time stack corresponding
-
-
-
-
JAVA 17
WHY FUNCTIONAL PROGRAMING
JAVA STREAM API
- write cleaner
- more concise
WHAT IS FP
- functions are treated as class
=>
- pass function as argument
- return function from other function
- use function as variables
core concept
- immutability: data is not change -> transformed
- pure function: same input -> same output / no side effect
- higher order function: take function as argument/return
key features:
- argument list
- arrow operator
- body
functional interface
- Consumer<T>
- Supplier<T>
- Function<T,R>
- Predicate<T>
-
- FunctionalInterface
- annomynous class
- java.ulti.function builtin package (Consumer, supplier...)
Functional interface
- allow only 1 abstract method into 1 interface
- dont care about default/static method
STREAM API
- java using functional approach with collection data
characteristics:
- lazy evaluation (need terminal operation is invoked)
- pipeline: operation is chained together
- non modifiying: streams dont alter original data source
- support parallel processing
component:
- data sources
- non terminal operation (filter, map, sort...)
- terminal operation (collect, foreach, reduce...)
tricky questions
- map - flatmap (nested array in array)
- findFirst (first element) - findAny (using for parallel -> return any element)
stream vs parallel stream
- stream: sequentially - 1 thread
- parallel: split data and process element using multiple threads
- collect parallel -> YES
- missing terminal operation -> lazy -> do not execute
- multiple terminal operation -> NO
-
-
new feature
record
- auto create getter to string, equal, ...
- avoid boilerplate code
- thread safe
-- cons:
- memory overhead since have to create new record after modifying data
- not flexible as mutable class
- create immutable DTO, value/config object
NOTE:
- do not use record as entity (JPA, hibernate) since JPA require mutable fields
- JPA create persitance object using empty constructor
-
sealed class
- manage child class
- declare which class can extend parent using permit keyword
small
- text block """ """
- switch case expression
- var for local valiable
KAFKA
distributed event streaming platform
- high throughput
- realiblity
- realtime processing
component
-
consumer groups:
- multiple consumer process same partition
- mapping principle: 1 consumer - 1 partition
-
-
topic
- like a channel, where events are stored and organized
partition
- topic split into partitions
- allow parallel processing of data
offset
- unique ID of each event in a partition
- used by consumers to track progress
-
-
broker
- server to store data serving producer/consumer
message
key:value
- retention: time/topic size
maintaining order
using key
- message with the same key go to the same partition
-
common issue
-
-
maintaning order
- add key
- avoid adding partitions later
Spring core module
Spring security
-
-
HOW
step
-
-
-
UsernameAndPasswordToken
from Token, Header, FormField, Cookie...
concept
servlet filter
request -> a couple of of filter chain -> Dispatcher Servlet -> Controllers
-
-
-
-
-
-
Thread pool
limit of thread
-
thread are expensive
thread có runtime stack, memory, regisster... của riêng nó
Solution
Threadpool
-
-
benefit
no need to manually create, start, join the threads
-
-
fault tolerance
-
fault tolerence
- resilience4j
- circuit breaker
- achieving resilience is blocking a failure from cascading and affecting
other components
- A - B work - closed
- B response failed -> register failure
- failure over threshold -> open
- any request to B -> failed
- waiting for recovering slowly - half - open
- close again
-
microservices logging and tracing patterns
- downside of ms is more difficult to debug, trace, and monitor issues. because 1 simple action can trigger numerous ms call in your app
- type: trace, debug, info, warm error
- common fw: logback(default), log4j2, log4j1
core component
log corellation:
- tie all logs produced bet ween services for a singler user transaction - traceID
correlationID
- randomly generated unique number
- propagate across multiple service
- spring sleuth
log aggregation
- pull all logs produced by ms
-
-
log
logs
application
fluent bit
- collect log from running container then foward to loki
loki
- store and make them searchable
- aggregate logs system, design to store and queries
tempo
- spans/trances like zipkin/jeager
- query -> result (trace view)
grafana
- grafana use loki as data source and visualize it
metrics
- cpu, ram...
- springboot actuator
prometheus
- like loki, prometheus is a metrics data source for grafana
-
-