Multiplayer pool game using Unity3d

1) Yes, it is. It will be OK, but not spectacularly accurate (because the physics engine they use is OK, but not specific to pool.)

2) Write a pool game. For each entity (pool ball, mostly) make sure that you have a reasonable sync mechanism among the options available in Unity.

3) You probably want some kind of turns, where one player isn't allowed to hit balls until another one is done with their shot. This can be done through a replicated variable that determines whose turn it is.

What I could really think of is :
1. Sending data of balls transform over network regularly within an Update(), which seems too expensive computationally!

2. Just sending the force vector over network at hit and let the physics engine handle all the physics computation based on the force vector .But i don't know how accurate will it be!

Regarding your mention of allowing players to hit or not can be done easily my maintaining Game States...
Now where should I head for ?

Sending data of balls transform over network regularly within an Update(), which seems too expensive computationally!

There's only 16 balls. How do you think a 16-player FPS game does networking?

Just sending the force vector over network at hit and let the physics engine handle all the physics computation based on the force vector .But i don't know how accurate will it be!

It is true that Unity doesn't use a deterministic simulation engine, and thus it doesn't allow you to ONLY send impact forces.
If I were to do pool on Unity, I'd probably send entity updates (position, orientation, velocity, spin) a dozen times per second, but I would also send special "impact events" whenever cue balls impact each other, that contain the exact position and direction of the balls affected by the impact.
However, I think the Unity physics networking code may already solve these things for you.

There's a great way for you to answer the questions you have:

1) Do some back-of-the-envelope math. How big is an update? 12 bytes pos, 12 bytes ori, 12 bytes velocity, 12 bytes spin, 4 bytes object ID? That's 52 bytes. Times 16 balls, equals 832 bytes. Less than a kilobyte for a full update. Send this 20 times a second, and you have less than 20 kB/sec per player (which is about 200 kbit/sec per player, give or take a bit of protocol overhead and rounding.) Seems plausible that it could work.

2) Actually implement it, and see how it goes. Especially, if there are already physics-based Unity game examples, use whatever API they're using and put a pool table together with 16 spheres. It doesn't need to be great gameplay, just a physics simulation experiment. Then see how it works. This kind of "spike" is very common in development and serves to inform decisions before a bigger effort is put into a particular direction.