Interview Prep Hub

25/03/2026

🚀 1 Concept in 60 Seconds: CQRS

Most systems get slower as they get bigger because the parts that change data and the parts that read data are fighting with each other.

CQRS, which is Command Query Responsibility Segregation solves this problem by keeping them separate.

The commands are in charge of changing data like when you create something update something or delete something.

The queries are in charge of reading data, like when you need to get some information.

This way the parts that change data can focus on making sure everything is correct and consistent.

The parts that read data can be made to work fast.

In life systems usually have a lot more people reading data than changing it.

CQRS helps because it lets you make the reading and writing parts work independently so you can make one part bigger without affecting the part.

You should use CQRS when your system has to handle a lot of people reading data and you need it to work fast and the rules of your business are complicated.

Do not use CQRS for applications that just create, read, update and delete data.

👉 So it is an idea to separate the parts of your system that change data from the parts that read data.

That is how you can make your system work well even when it gets really big.

25/03/2026

අපේ අද article එකෙන් බලමු Command Query Responsibility Segregation නැත්නම් CQRS කියන්නෙ මොකක්ද කියලා.

අපි application එකක් implement කරන්න පටන් ගන්නකොට හරිම simple විදියට එක service එකක්, එක model එකක් හදලා reads ,writes සේරම එකම place එකකින් handle වෙන විදියට හදන්න පුලුවන්. මේක build, understand සහ develop කරන්න ලේසි. හැබැයි මේ application එකේ ප්‍රශ්න එන්න ගන්නෙ මේක grow වෙද්දි. එතකොට queries slow වෙන්න, business logics maintenance hard වෙන්න සහ scaling වලදි ප්‍රශ්න ඇති වෙන්න පුලුවන්. මෙන්න මේ වගේ scenario වලදි අපිට CQRS use කරන්න පුලුවන්.

🧠What is CQRS ?

මේකෙ core idea එක තමයි data modify කරන operations සහ data read කරන operations separate කරන එක.

මේ pattern එකේදි commands කියන්නෙ system state එක වෙනස් කරන create, update or delete වගේ operations. Queries කියන්නෙ data retrieve කරන operations. උදාහරණයක් විදියට create user, update user, get users, search users වගේ operations සේරම include කරලා Users Service එක හදනවා වෙනුවට create users සහ update user function include කරලා User Command Service එකත් get users සහ search users function include කරලා User Query Service එකත් හදන්න මේ pattern එකේදි පුලුවන්.

⚡Why CQRS is Powerful ?

CQRS වලදි clean separation එකක් තියෙන නිසා read සහ write sides වෙන වෙනම evolve කරන්න පුලුවන්. ඒ කියන්නෙ write side එකේදි business rules enforce කරන්න සහ data integrity එක focus කරන්නදි read side එකේදි denormalization, caching වගේ techniques use කරලා speed එක optimize කරන්නත් පුලුවන්. ඕන නම් separate databases උනත් use කරන්න පුලුවන්.

🏗️A Real-World Example

අපි උදාහරණයක් විදියට e-commerce application එකක් ගමු. මේ application එකෙන් අපි order එකක් place කරනකොට business rules validate කරන්න, payment process කරන්න සහ consistency එක maintain කරන්න ඕන. මේ operations අපිට command side එකේ include කරන්න පුලුවන්.

ඒ වගේම user එකෙන් order history එක බලන එක, admin කෙනෙක් sales reports බලන එක වගේ data quickly return කරන්න ඕන operations අපිට query side එකට include කරන්න පුලුවන්.

⚖️Trade-Offs

CQRS pattern එකේ benefits තිබුනට මේකෙන් additional complexity එකක් add වෙන නිසා මේක ටිකක් costly. Data synchronization , read සහ write side අතරෙ eventual consistency එක maintain කරනවා වගේ challenges handle කරන්න වෙනවා.

🎯When CQRS makes Sense

Complex business logics සහ high read traffic එකක් තියෙන system වලදි මේ CQRS pattern එක ගොඩක් useful. ඒ වගේම large scale applications, micro services architectures, සහ high performance and scalability එකක් ඕන වෙන system වලදි අපිට CQRS use කරන්න පුලුවන්.

මේ වගේ තව article එකකින් වෙන දවසක හම්බ වෙමු.

25/03/2026

අපේ කලින් article එකෙන් අපි REST API endpoints වල naming convention ගැන බැලුවා. අද අපි බලමු REST API එකක් design කරනකොට අපි follow කරන API versioning best practices ගැන.

ඇයි අපි API versioning කරන්න ඕන? අපි හදන API එකක් හැමදාම එකම විදියට තියෙන්නෙ නෑ. System එකක් evolve වෙනකොට new features introduce වෙන්න, response format change වෙන්න, endpoints change වෙන්න වගේ ගොඩක් changes වෙන්න පුලුවන්.

මේ changes, proper strategy එකක් නැතුව introduce කරොත්, දැනට මේ API එක use කරන client applications break වෙන්න පුලුවන්. මෙන්න මේ හේතුව නිසා තමයි API එකක් design කරද්දි අපි versioning ගැන බලන්න ඕන. අපි proper versioning strategy එකක් use කරාම අපිට existing integrations break වෙන්නෙ නැතුව changes introduce කරන්න පුලුවන්.

🍀 Common API Versioning Approaches

1. URL Versioning

මේ approach එකේදි API version එක directly, endpoint එකේ include කරනවා.

GET /api/v1/users
GET /api/v2/users

මේ approach එක clear ඒ වගේම visible. Manage කරන්නත් ලේසි සහ REST API වල widely use වෙන approach එකක්.

2. Header Versioning

මේ approach එකේදි API version එක request header එකේ specify කරනවා.

Accept: application/vnd.myapi.v2+json

මේ approach එකේදි URL එකේ version එක include කරන්නෙ නැති නිසා URL එක clean. ඒ වගේම API evolution වලට ගොඩක් flexible.

3. Query Parameter Versioning

මේ approach එකේදි අපි API version එක specify කරන්නෙ query parameter එකක් විදියට.

GET /users?version=2

මේ approach එක simple ඒත් ගොඩක් large APIs වල widely use වෙන්නෙ නෑ.

🍀When Should We Introduce a New Version ?

අපි API එකට breaking change එකක් introduce කරනකොට normally අලුත් API version එකක් introduce කරනවා. උදාහරණයක් විදියට

1. Fields remove කරද්දි
2. Response structure එක change කරද්දි
3. Authentication behavior එක change කරද්දි
4. Endpoints semantics change කරද්දි

අපිට අලුත් API version එකක් introduce කරන්න පුලුවන්. ඒ වගේම optional fields add කරනවා වගේ non-breaking change එකක් කරාට usually new version එකක් introduce කරන්න ඕන නෑ.

මේ වගේ තව article එකකින් වෙන දවසක හම්බ වෙමු.

25/03/2026

අපේ අද article එකෙන් බලමු අපි REST API එකක් implement කරනකොට follow කරන්න ඕන best practices ගැන.

Backend system එකක් implement කරද්දි API එක කියන්නෙ services සහ client අතරෙ තියෙන contract එකක්. අපි API එක හොදට design කරොත් system එක understand කරන්න, integration සහ maintenance ලේසි. ඒක නිසා හොද API එකක clear and consistent endpoints තියෙන්න ඕන.

අපි දැන් බලමු මේ විදියට follow කරන්න පුලුවන් REST API naming conventions ටිකක්.

1. Use nouns instead of verbs

Endpoint එකකින් represent වෙන්නෙ actions නෙවේ resources. අපි perform කරන operation එක අනුව use වෙන්න ඕන HTTP method එක already define වෙලා තියෙනවා.

✔ GET /users → retrieve users
✔ POST /orders → create an order
✔ DELETE /orders/101 → delete an order

ඒක නිසා මේ වගේ verb-based endpoints avoid කරන්න.

❌ /getUsers
❌ /createOrder
❌ /deleteUser

මේ විදියට resource-oriented endpoints හැදුවම API එක predictable සහ intuitive.

2. Use plural resource names

සාමාන්‍යයෙන් REST API වලින් resources collection එකක් represent වෙනවා. ඒක නිසා plural naming preferable.

✔ /users
✔ /products
✔ /orders

Single resources වලට මේ විදියට endpoints හදන්න පුලුවන්.

✔ /users/15
✔ /orders/101

මේ විදියට අපිට resources collection එකක් හා individual resource එකක් clearly වෙන් කරලා පෙනන්න පුලුවන්.

3. Use hierarchical structure for relationships

User ID එක 15 වෙන user ට අදාල orders fetch කරන්න වගේ scenario වලදි අපිට nested paths use කරන්න පුලුවන්.

✔ /users/15/orders → orders belonging to a user
✔ /orders/101/items → items inside an order

4. Use query parameters for filtering and searching

Filter සහ search operations වලට වෙන වෙනම endpoints create කරනවා වෙනුවට query parameters use කරන්න පුලුවන්. මේ විදියට අපේ API එක flexible වෙනවා වගේම unnecessary endpoints avoid කරගන්න පුලුවන්.

✔ /products?category=electronics
✔ /orders?status=completed
✔ /users?country=SriLanka

5. Keep endpoints simple and consistent

Maintenance difficult වෙන නිසා ගොඩක් complex paths හදන්න එපා. API එකේ consistency එක developer experience එක improve කරනවා.

Good examples:
✔ /products/25
✔ /products?limit=10&offset=20

6. Use lowercase and hyphens

මේකෙන් අපිට readablility එක සහ consistency එක improve කරන්න පුලුවන්.

✔ /user-profiles
✔ /order-items

Avoid:
❌ /UserProfiles
❌ /orderItems

7. Version your APIs

APIs, time එකත් එක්ක evolve වෙන නිසා proper strategy එකක් use කරලා API එක versioning කරන්න ඕන. මේ විදියට versioning කරන්න පුලුවන් විදි කීපයක් තියෙනවා. අපි ඒක වෙන දවසක බලමු.

✔ /api/v1/users
✔ /api/v2/orders

මේ විදියට අපි properly versioning කරාම changes වලදි existing systems break වෙන්නෙ නෑ.

මේ වගේ තව article එකකින් වෙන දවසක හම්බ වෙමු.

25/02/2026

අපේ අද article එකෙන් බලමු Microservice Architecture එකේදි use වෙන Saga Pattern එක ගැන.

Monolithic application වලදි transaction management සරලයි. ACID properties use කරලා අපිට එක database එකක consistency එක ensure කරන්න පුලුවන්.

හැබැයි microservice architecture එකේදි අපි database per service pattern එක use කරනවා. එතකොට services වලට වෙන වෙනම dedicated separate databases තියෙනවා. මෙතනදි services කීපයක් අතරෙ business operations span උනාම consistency maintain කරන එක challenging. මේ වගේ අවස්ථා වලදි Distributed Transactions use වෙනවා.

🍀 Distributed Transactions

එක් business process එකක් කරන්න services or databases කීපයක changes වෙනවනම් ඒක distributed transaction එකක් කියලා හදුන්වන්න පුලුවන්. උදාහරණයක් විදියට e-commerce application වලදි order එකක් place කරාම Order database, payment database සහ inventory database එක update වෙන්න පුලුවන්. මේවා separate services. එක step එකක් fail වෙලා අනෙක් steps success උනොත් system එක inconvenient state එකකට එන්න පුලුවන්.

🍀Two-Phase Commit (2PC)

අපිට මේ distributed transactions handle කරන්න 2PC mechanism එක use කරන්න පුලුවන්. මෙතනදි central coordinator එකක් මගින් අදාල services වල transactions manage කරනවා. හැබැයි මේ approach එක tight coupling සහ ගොඩක් scalable නෑ.

🍀What is the Saga Pattern ?

Two-Phase Commit approach එකට alternative එකක් විදියට තමයි saga pattern එක introduce වෙන්නෙ. සරලවම මේ pattern එකේදි එක service එකක් අදාල transaction එක complete කරාම event එකක් publish කරනවා. ඒ publish වෙන event එකට listen කරලා අනෙක් services අදාල transactions කරනවා.

Saga pattern එකේ ප්‍රධාන types දෙකක තියෙනවා.

1. Choreography-Based Saga

මේ approach එකේ central coordinator කෙනෙක් නෑ. සෑම service එකක්ම events වලට listen කරලා, local transaction perform කරාට පස්සෙ event එකක් publish කරනවා.

උදාහරණයක් විදියට Order Service එක OrderCreated event එක publish කරාම Payment service එක ඒකට listen කරලා payment එක process කරලා PaymentCompleted event එක publish කරනවා. මේ event එකට Invetory Service එක listen කරලා stocks reserve කරනවා.

දැන් අපි failure scenario එකක් බලමු. මෙතනදි Inventory Service එක fail උනොත් InventoryFailed event එකක් publish කරන්න පුලුවන්. මේ event එකට Payment Service එකන් listen කරලා refund process එක trigger කරන්න පුලුවන්. ඒ වගේම Order Service එකේ order status එක Cancelled විදියට update කරන්න පුලුවන්.

මේ approach එක loosely coupled , highly scalable වගේම event-driven system එක්ක හොදට වැඩ කරනවා. හැබැයි event chain එක messy වෙන්න තියෙන ඉඩ වැඩි. ඒක නිසා flow එක visualize කරන එක hard වගේම debugging complex වෙනවා.

2. Orchestration-Based Saga

මේ approach එකේදි Saga Orchestrator එකෙන් workflow එක control කරනවා. ඒ කියන්නෙ events වලට blindly react කරන්නෙ නැතුව services, orchestrator එක විසින් explicitly instruct කරනවා.

මේ approach එක clear ඒ වගේම traceable. ඒ වගේම monitoring සහ logging වලටත් ලේසි. Complex business process වලට suitable. හැබැයි මෙතනදි Orchestrator එක කියන්නෙ critical component එකක්.

ERP, Banking වගේ complex workflows තියෙන enterprise-grade system වලට Orchestration ගොඩක් suitable.

18/02/2026

අද අපේ article එකෙන් බලමු SQL වල, හොද query optimization එකක් ගන්න follow කරන්න පුලුවන් tips ටිකක්.

1. Select Only What You Need : සරලවම අනවශ්‍ය විදියට select * use කරන්න එපා. ඒ වෙනුවට අපිට ඕන වෙන filed ටික විතරක් retrieve කරන්න.

Less data = less memory + faster I/O

2. Index Smartly (Not Excessively) : Indexes වලින් අපේ reads speed up කරගන්න පුලුවන්. හැබැයි අපි අනවශ්‍ය විදියට ගොඩක් indexes create කරොත් වෙන්නෙ write operations slow වෙන එක. ඒක නිසා best practice එකක් විදියට අපිට frequently filtered columns, join columns, High-cardinality fields වලට indexes හදන්න පුලුවන්.

3. Use Composite Indexes Properly : Order matters. අපි (first_name, last_name) composite index එකක් හැදුවොත් last_name වලින් විතරක් filter කරද්දි මේ index එකෙන් help එකක් නෑ.

4. Avoid Functions in Where Clause : WHERE YEAR (created_at) = 2025 මේ වගේ where clause එකේ functions use කරාම function එකෙන් indexes use වෙන එක වලක්වනවා.

5. Prefer EXISTS Over IN (for large datasets) : Subqueries එක්ක වැඩ කරනකොට ගොඩක් වෙලාවට EXISTS use කරාම performance වැඩී.

6. Avoid Unnecessary DISTINCT : DISTINCT use කරාම internally dataset එක sort වෙනවා. Sorting = expensive

7. Use LIMIT for Pagination : UI එකේ rows 20යි නම් පෙන්නන්නෙ entire dataset එකම query කරලා memory එකට ගන්න එපා.

8. Understand Ex*****on Plans : සරලවම අපි execute කරන query එකක් database එකේ process වෙන්නෙ කොහොමද කියලා අපිට ex*****on plan එකෙන් බලාගන්න පුලුවන්. මේකෙන් අපි හදපු indexes hit වෙනවද, full table reads යනවද වගේ ගොඩක් information ගන්න පුලුවන්.

9. Avoid N+1 Query Problem : මේක අපි query ලියනකොට ගොඩක් වෙලාවට කරන mistake එකක්. මේකට අපිට Joins or batch queries use කරන්න පුලුවන්.

10. Normalize, but Don't Over-Normalize : Normalization වලින් අපිට data redundancy එක අඩු කරගන්න පුලුවන්. ඒත් excessive joins නිසා performance අඩු වෙන්නත් පුලුවන්. ඒක නිසා Normalization, balance එකේ කරන්න ඕන.

11. Use Proper Data Types : සරලවම small value එකක් store කරන්න BIGINT use කරන්න එපා. Filed එකේ store කරන data බලලා data type එක decide කරන්න.

12. Avoid Leading Wildcards : WHERE name LIKE '%john' මේ වගේ leading wildcards use කරාම indexes use වෙන්නෙ නෑ.

13. Use Batch Insert : එක row එකෙන් row එකට INSERT INTO ලියන්නෙ නැතුව එක INSERT INTO එකෙන් rows කීපයක් insert කරන්න පුලුවන්.

14. Keep Transactions Short : Long transactions = locked rows = blocked users

15. Avoid OR in Large Conditions

16. Use Proper Join Types

17. Archive Old Data : Huge tables නිසා system එකම slow වෙන්න පුලුවන්. ඒක නිසා historical data අපිට archive tables වල තියන්න පුලුවන්.

18. Monitor Query Time : මේකෙන් අපිට slow queries identify කරගන්න පුලුවන්.

19. Avoid Overusing Views : Complex nested views නිසා hidden performance issues ඇති වෙන්න පුලුවන්.

20. Test With Realistic Data : අපේ queries, production-like data volume එකකට against check කරන්න ඕන.

07/01/2026

අද අපි බලමු Relational Database වල Columnstore Index කියන්නෙ මොකක්ද කියලා 💡

Massive datasets එක්ක වැඩ කරනකොට performance කියන්නෙ challenge එකක්. Analystics and reporting queries ගොඩක් වෙලාවට rows million ගනන් scan කරනවා. මේ වගේ scenario වලදි performance වැඩි කරගන්න අපිට මේ Columnstore Index use කරන්න පුලුවන්.

අපි මුලින්ම Row-Oriented Storage එක ගැන බලමු.

🍀 Row-Oriented Storage

Traditional table එකක එක row එකකින් එක record එකක් represent වෙනවා. සමහර වෙලාවට අපිට query කරන්න ඕන වෙන්නෙ columns කීපයක් විතරයි. හැබැයි row-oriented storage එකකදි අපිට අවශ්‍ය columns ටික extract කරගන්න entire row එකම memory එකට ගන්න වෙනවා. Rows විශාල ප්‍රමානයක් query කරන analytical queries වගේ query වලදි මේ විදිට inefficient. උදාහරණයක් විදියට හිතන්න rows million ගානක් තියෙන retail transaction table එකක්. මේ table එකේ columns විදියට TransactionID, CustomerID, ProductID, Quantity, UnitPrice, TransactionDate, StoreLocation, PaymentMethod වගේ columns තියෙන්න පුලුවන්. අපිට specific day එකක total sales බලාගන්න ඕන උනාම TransactionDate column එක use කරලා ඒ date එකට අදාල records ටික ගන්න පුලුවන්. හැබැයි Quantity * UnitPrice වල sum එක ගන්න අපිට මුලු row එකම fetch කරන්න වෙනවා.

🍀Column-Oriented Storage (Columnstore Index)

සරලවම columnstore index එකකදි data store වෙන්නෙ column විදියට. සෑම column එකක්ම separately store වෙනවා. ඒ වගේම column එක තුල data compress වෙනවා. Columnstore index එකෙන් අපිට advantages කීපයක් ලබාගන්න පුලුවන්.

1. Reduced I/O: අපි columns කීපයක් පමනක් query කරනකොට, database එක disk එකෙන් read කරන්න ඕන මේ specific column විතරයි. ඒක නිසා I/O operations reduce වෙනවා.

2. Enhanced Compression:Column එකේ තියෙන data සේරම typically same data type. ඒ වගේම similar values තියෙන්න පුලුවන්. ඒක නිසා row-oriented storage එකකට වඩා compression ratio එක වැඩී. Disk space usage එක මේ නිසා අඩු වෙනවා.

3. Vectorized Query Processing: සරලවම අපිට aggression, filtering වගේ operations, column එක තුල batch විදියට simultaneously කරන්න පුලුවන්. Row-by-row යන්න ඕන නෑ. ඒක නිසා CPU එක efficiently utilize කරන්න පුලුවන්.

අපි කලින් ගත්ත retail transaction table example එකම columnstore index එකට apply කලොත්, මෙතනදි අපිට read කරන්න වෙන්නෙ TransactionDate, Quantity සහ UnitPrice column විතරයි. මේ column සේරම separately store වෙලා තියෙනවා. Query engine එකට මේ columns, batch විදියට efficiently process කරලා sum එක ගන්න පුලුවන්.

28/11/2025

🚨 We’re Live Now! 💚
Join us for the first-ever Vue.js Sri Lanka Virtual Meetup 🎉

🎙️ Why Vue.js — The Evolution of Single Page Applications
by Nico Devs, Senior Software Engineer at Tighten

📺 Watch Live on YouTube:
👉 https://shorturl.at/oM6hg

Hop in, learn, and be part of the Sri Lankan Vue.js community’s first chapter! ⚡

13/11/2025

We are super excited to share that we’re hosting our first-ever Virtual Meetup! 🇱🇰💚

It’s going to be an awesome opportunity to connect, learn, and grow together as Vue developers.
Details coming soon — you don’t want to miss this! ⚡

Something exciting is brewing for all Vue lovers in Sri Lanka 🇱🇰💚

We’re getting ready to host our first-ever Vue.js Sri Lanka Virtual Meetup!

Stay tuned — details dropping soon! ⚡

06/11/2025

Java Concept Breakdown Article Series එකෙන් අද අපි බලමු Java වල Runnable සහ Callable Interfaces ගැන.

අපි Java program එකක් develop කරනකොට data fetch කරන්න, computations කරන්න සහ background jobs perform කරන්න වගේ tasks වලට separate threads බහුලව use කරනවා. මෙන්න මේ වැඩේ කරගන්න තමයි අපිට මේ Runnable සහ Callable Interfaces දෙක ඕන වෙන්නෙ.

මේ interfaces දෙක use කරලා අපිට thread එකකින් හෝ executor එකකින් execute වන tasks represent කරන්න පුලුවන්. හැබැයි මේ interfaces දෙකේ results, exceptions සහ ex*****on control handle වෙන විදිය වෙනස්. අපි බලමු ඒ differences මොනවද කියලා.

🧵What is Runnable?

Runnable තමයි මේ interface දෙකෙන් simple ම interface එක. මේකෙන් අපිට result එකක් return කරන්නෙ නැති task එකක් represent කරන්න පුලුවන්. මේක introduce කරේ Java 1.0 වලදි. ඒ වගේම මේකෙ run() method එක තියෙනවා.

public interface Runnable {
void run();
}

Exception handling නැති සහ value එකක් return කරන්නෙ නැති task වලට අපිට runnable interface එක use කරන්න පුලුවන්. (fire-and-forger tasks)

⚙️What is Callable?

Java 5 වල java.util.concurrent package එකේදි callable interface එක introduce කරේ runnable interface එකේ තියෙන limitations address කරන්න. මේකෙන් අපිට result එකක් return කරන සහ checked exceptions throw කරන tasks represent කරන්න පුලුවන්.

public interface Callable {
V call() throws Exception;
}

මේකෙදි V වලින් represent කරන්නෙ task එකෙන් return කරන result එකේ type එක. අපි callable instance එකක් executor service එකකට submit කරාම Future object එකක් return වෙනවා. අපිට මේ future object එක use කරලා results retrieve කරගන්න පුලුවන්. ඒ වගේම task එක complete ද කියලා බලන්නත් පුලුවන්.

🌍Real-World Usage

Logging or monitoring services implement කරනකොට අපිට Runnable interface එක බහුලව use කරන්න පුලුවන්. උදාහරණයක් විදියට periodically logs write කරන background threads වලට අපිට Runnable use කරන්න පුලුවන්.

API වලින් data fetch කරන්න, long-running computations කරන්න වගේ return value එකක් තියෙන tasks වලට callable interface එක use කරන්න පුලුවන්.

23/10/2025

Java Concept Breakdown Article Series එකෙන් අද අපි බලමු Java වල Threads සහ Executors ගැන.

අපි efficient java application එකක් develop කරනකොට concurrency management කියන්නෙ ගොඩක් important aspect එකක්. Java වලදි multitasking handle කරන්න ක්‍රම කීපයක් තියෙනවා. මේ අතරින් Threads සහ Executors කියන්නෙ commonly use වෙන approach දෙකක්. මේ approach දෙකම use වෙන්නෙ tasks concurrently execute කරන්න. හැබැයි මේ approach දෙක වැඩ කරන විදිය significantly වෙනස්.

🧵What are Threads?

සරලව thread එකක් කියන්නෙ process එකක execute වන smallest unit එක. Java වලදි අපිට Thread class එකෙන් extend කරලා හෝ Runnable or Callable interface implement කරලා thread එකක් හදන්න පුලුවන්. මේ threads independently run වෙනවා. හැබැයි manually threads manage කරන එක ටිකක් complex.

අපි manually threads manage කරනවනම් thread creation සහ ඒ threads වල lifecycle එක handle කරන්න ඕන. ඒ වගේම threads ගොඩක් start කරොත් high memory consumption එකක් වෙන්න පුලුවන්. ඒ වගේම threads අතරෙ coordination සහ safely threads shut down කරන එක tricky.

ඒක නිසා මේ approach එක small programs වලට manageable උනත් large or concurrent systems වලදි හොදින් scale වෙන්නෙ නෑ.

⚙️What Are Executors?

Thread management simplify කරන්න Java 5 වලදි Executor framework එක introduce කරලා තියෙනවා.

මෙතනදි වෙන්නෙ අපි threads manually create සහ manage කරනවා වෙනුවට, task එකක් executor එකට submit කරන්න පුලුවන්. එතකොට executor එකෙන්, thread allocation, ex*****on සහ termination control කරනවා. මේක කරන්න executor එක thread pool එකක් use කරනවා. මේ නිසා අපිට constantly thread create සහ destroy කරන overhead එක අඩු කරගන්න පුලුවන්. ඒ වගේම performance සහ scalability එක වැඩි වෙනවා. ඒ වගේම අපේ විවිද use case වලට ගැලපෙන executors කීපයක්ම තියෙනවා.

🔹 Executors.newSingleThreadExecutor() – for sequential task ex*****on.
🔹Executors.newFixedThreadPool(n) – for a fixed number of threads.
🔹Executors.newCachedThreadPool() – for dynamic thread management.

Real world usage එක ගැන බැලුවොත් අපිට background timers වගේ light-weight, single purpose scenario වලට threads use කරන්න පුලුවන්. Web server එකක multiple client request handle කරන්න, microservices වලදි worker tasks manage කරන්න, spring boot / Java EE වගේ framework වලදි parallel computations කරන්න වගේ වැඩ වලට අපිට executors use කරන්න පුලුවන්.

මේ වගේ තව article එකකින් අපි වෙන දවසක හම්බ වෙමු.